From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 19 04:35:50 2005 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 6C04716A41F for ; Sun, 19 Jun 2005 04:35:50 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2969943D1D for ; Sun, 19 Jun 2005 04:35:50 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5J4Zjv1046546; Sat, 18 Jun 2005 21:35:49 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5J4Zd2s046543; Sat, 18 Jun 2005 21:35:39 -0700 (PDT) (envelope-from obrien) Date: Sat, 18 Jun 2005 21:35:39 -0700 From: "David O'Brien" To: Scott Long Message-ID: <20050619043539.GA46516@dragon.NUXI.org> References: <42B409A7.5020909@mail.uni-mainz.de> <42B417C7.80904@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42B417C7.80904@samsco.org> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: 6.0-Current and gcc 4.x X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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: Sun, 19 Jun 2005 04:35:50 -0000 On Sat, Jun 18, 2005 at 06:47:03AM -0600, Scott Long wrote: > Given all the disruptions in the past 3 years over gcc > 3.x, I think it would be nice to take a small break and not be on the > bleeding edge of gcc. I think you're grossly over exagerating the "disruptions" over GCC 3.x. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 19 04:37:13 2005 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 7AA6D16A41F for ; Sun, 19 Jun 2005 04:37:13 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50C7543D53 for ; Sun, 19 Jun 2005 04:37:13 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5J4bC1k046574; Sat, 18 Jun 2005 21:37:12 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5J4bBkF046573; Sat, 18 Jun 2005 21:37:11 -0700 (PDT) (envelope-from obrien) Date: Sat, 18 Jun 2005 21:37:11 -0700 From: "David O'Brien" To: Steve Kargl Message-ID: <20050619043711.GB46516@dragon.NUXI.org> References: <42B409A7.5020909@mail.uni-mainz.de> <20050618162922.GE55448@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050618162922.GE55448@troutmask.apl.washington.edu> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: "O. Hartmann" , freebsd-amd64@freebsd.org Subject: Re: 6.0-Current and gcc 4.x X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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: Sun, 19 Jun 2005 04:37:13 -0000 On Sat, Jun 18, 2005 at 09:29:23AM -0700, Steve Kargl wrote: > On Sat, Jun 18, 2005 at 01:46:47PM +0200, O. Hartmann wrote: > > As I see in the sources, FreeBSD 6.0-Current is still based on gcc > > 3.4.4. I think due to code freezing this version will be the platform > > compiler when 6.0-RELEASE comes out. Are there any plans using a more > > recent version of gcc, like 4.0 or 4.1? On some lists I read something > > about better support of the features of AMD64/EM64T architectures, > > especially SSE3. > > It's David O'Brien and Kan's call, but I would recommend > against the use of gcc 4.0.0. GCC is in the process of > (early) release of 4.0.1 due to serious bugs affecting > compilation of C++ and KDE. One definately would want to wait for a point release after a major GCC version bump. Same for anyone basing product on FreeBSD. :-) -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 19 04:40:04 2005 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 CE7BF16A41F for ; Sun, 19 Jun 2005 04:40:04 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9736743D49 for ; Sun, 19 Jun 2005 04:40:04 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5J4e3DA046614; Sat, 18 Jun 2005 21:40:03 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5J4e2Au046611; Sat, 18 Jun 2005 21:40:02 -0700 (PDT) (envelope-from obrien) Date: Sat, 18 Jun 2005 21:40:02 -0700 From: "David O'Brien" To: NAKAJI Hiroyuki Message-ID: <20050619044002.GC46516@dragon.NUXI.org> References: <861x70h6g3.fsf@ra333.heimat.gr.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <861x70h6g3.fsf@ra333.heimat.gr.jp> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@FreeBSD.org Subject: Re: HDAMD, 39320A-R and U320 disks X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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: Sun, 19 Jun 2005 04:40:05 -0000 On Sat, Jun 18, 2005 at 09:09:00AM +0900, NAKAJI Hiroyuki wrote: > o Rioworks HDAMD What BIOS version are you using? The latest one for your revision of HDAMD? -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 19 05:58:56 2005 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 0A27416A41C for ; Sun, 19 Jun 2005 05:58:56 +0000 (GMT) (envelope-from peterk@maltanet.net) Received: from maltanet.net (mailer4.maltanet.net [194.158.37.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59CCA43D1F for ; Sun, 19 Jun 2005 05:58:54 +0000 (GMT) (envelope-from peterk@maltanet.net) Received: (qmail 3977 invoked by uid 516); 19 Jun 2005 06:06:44 -0000 Received: from 195.158.86.17 by mailer4.maltanet.net (envelope-from , uid 509) with qmail-scanner-1.25st (perlscan: 1.25st. Clear:RC:1(195.158.86.17):. Processed in 0.260143 secs); 19 Jun 2005 06:06:44 -0000 Received: from unknown (HELO [192.168.1.1]) ([195.158.86.17]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 19 Jun 2005 06:06:43 -0000 Message-ID: <42B5099C.90109@maltanet.net> Date: Sun, 19 Jun 2005 07:58:52 +0200 From: Peter Korsten User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: nl-NL, nl, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <42B409A7.5020909@mail.uni-mainz.de> <42B417C7.80904@samsco.org> <20050619043539.GA46516@dragon.NUXI.org> In-Reply-To: <20050619043539.GA46516@dragon.NUXI.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: 6.0-Current and gcc 4.x 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: Sun, 19 Jun 2005 05:58:56 -0000 David O'Brien schreef: > On Sat, Jun 18, 2005 at 06:47:03AM -0600, Scott Long wrote: > >>Given all the disruptions in the past 3 years over gcc >>3.x, I think it would be nice to take a small break and not be on the >>bleeding edge of gcc. > > I think you're grossly over exagerating the "disruptions" over GCC 3.x. I remember having to go back a version of GCC 3.x, because it wouldn't actually compile code. And going back with GCC is not a fun thing to do if you don't have a working compiler. - Peter From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 19 09:47:52 2005 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 9765016A41C for ; Sun, 19 Jun 2005 09:47:52 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.178.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29E4343D1F for ; Sun, 19 Jun 2005 09:47:51 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from [134.93.180.218] (edda.Physik.Uni-Mainz.DE [134.93.180.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate2.zdv.Uni-Mainz.DE (Postfix) with ESMTP id C390D300049E; Sun, 19 Jun 2005 11:47:50 +0200 (CEST) Message-ID: <42B53F24.8020300@mail.uni-mainz.de> Date: Sun, 19 Jun 2005 11:47:16 +0200 From: "O. Hartmann" Organization: Institut =?UTF-8?B?ZsO8ciBHZW9waHlzaWs=?= User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050424) X-Accept-Language: en-us, en MIME-Version: 1.0 To: delphij@delphij.net References: <42B409A7.5020909@mail.uni-mainz.de> <1119099681.759.22.camel@spirit> In-Reply-To: <1119099681.759.22.camel@spirit> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Cc: freebsd-amd64@freebsd.org Subject: Re: 6.0-Current and gcc 4.x 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: Sun, 19 Jun 2005 09:47:52 -0000 Xin LI wrote: > Hi, > > 在 2005-06-18六的 13:46 +0200，O. Hartmann写道： > >>Hi. >>As I see in the sources, FreeBSD 6.0-Current is still based on gcc >>3.4.4. I think due to code freezing this version will be the platform >>compiler when 6.0-RELEASE comes out. Are there any plans using a more >>recent version of gcc, like 4.0 or 4.1? On some lists I read something >>about better support of the features of AMD64/EM64T architectures, >>especially SSE3. > > > Currently there is no plan to upgrade to GCC 4.x. We are in a code > slush for preparation of RELENG_6 right now, since GCC 4.x import would > involve a large scale code modification All right, I think this is one of the most important aspects. > (some of our code would not > compile on gcc 4.x since it is more picky than 3.x series, and some of > gcc 3.x features has been removed since they are not ISO C/C++ and > certain part of our code has utilized these features), and causes > performance degradation on i386 architecture, I don't think we will > import gcc 4.x in FreeBSD 6.x. I wasn't aware of those restrictions. I also did not recognize the 'Nocona' switch which obviously offers the SSE3 option for Intel/EM64T add ons. I remember of some discussions herein about mapping this flag into Athlon64/Opteron world, sorry for that. Maybe this is a bit of off topic, but I'm curious about why gcc 4.0 let FreeBSD run into performance penalties. May you give me a hint for further digging the net? I'm interested in this. > > Help on making FreeBSD compile on newer compiler(s) and clean up the > code base is always appreciated, of course :-) Meantime you would be > able to get latest GCC 4.x from our ports collection. And another point i did not thought of (ports collection). > > Cheers, Also off topic: Well, the major intention is to use a faster C and/or free Fortran compiler doing my numerical research on FreeBSD boxes. In most cases I gained success on compiling Fortran90 code with PGI and/or Intel V8 compilers, running this code on FBSD 5.3/4 boxes within the Linuxulator. I found out that some C code performs not that fast as expected using PGI or Intel C compiler, but Fortran code (F77) performs really faster (fast in the manner of: it is useable!). On a pure AMD64-FreeBSD 5.4-STABLE box I feel like a dead man in the water because I do not have access to a 64Bit Linuxulator using the 64Bit versions of Intel or PGI (which gave me a real boost on our SuSE Linux Cluster, but I do not wish to develop under Linux, sorry). All right, that's a bit apart of the main question. Thanks for your response. Oliver From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 19 17:00:39 2005 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 1EC9516A41C for ; Sun, 19 Jun 2005 17:00:39 +0000 (GMT) (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 D725D43D4C for ; Sun, 19 Jun 2005 17:00:38 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5JH0cLo049857 for ; Sun, 19 Jun 2005 17:00:38 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5JH0cdK049856; Sun, 19 Jun 2005 17:00:38 GMT (envelope-from gnats) Resent-Date: Sun, 19 Jun 2005 17:00:38 GMT Resent-Message-Id: <200506191700.j5JH0cdK049856@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, Jophn Deo Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1735E16A41F for ; Sun, 19 Jun 2005 16:54:19 +0000 (GMT) (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 007C643D1D for ; Sun, 19 Jun 2005 16:54:18 +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 j5JGsIft089557 for ; Sun, 19 Jun 2005 16:54:18 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j5JGsImc089556; Sun, 19 Jun 2005 16:54:18 GMT (envelope-from nobody) Message-Id: <200506191654.j5JGsImc089556@www.freebsd.org> Date: Sun, 19 Jun 2005 16:54:18 GMT From: Jophn Deo To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/82422: Stop in /usr/ports/devel/gettext/work/gettext-0.14.5 error 1 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: Sun, 19 Jun 2005 17:00:39 -0000 >Number: 82422 >Category: amd64 >Synopsis: Stop in /usr/ports/devel/gettext/work/gettext-0.14.5 error 1 >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jun 19 17:00:38 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Jophn Deo >Release: 5.4 >Organization: >Environment: 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May 8 07:00:26 UTC 2005 root@portnoy.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Install any app which depends on gettext-0.14.5 and you get the error message. Stop in /usr/ports/devel/gettext. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade21883.1 make Warning: arch-dependent data dir (/usr/local/libexec/emacs/21.3/amd64--freebsd/) does not exist. Warning: arch-independent data dir (/usr/local/share/emacs/21.3/etc/) does not exist. Warning: Lisp directory `/usr/local/share/emacs/21.3/site-lisp' does not exist. Warning: Lisp directory `/usr/local/share/emacs/21.3/leim' does not exist. Warning: Lisp directory `/usr/local/share/emacs/21.3/lisp' does not exist. Cannot open load file: bytecomp *** Error code 1 >How-To-Repeat: Install any app which depends on gettext-0.14.5 >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 19 17:30:39 2005 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 49A9116A41F; Sun, 19 Jun 2005 17:30:39 +0000 (GMT) (envelope-from matteo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D80143D48; Sun, 19 Jun 2005 17:30:39 +0000 (GMT) (envelope-from matteo@FreeBSD.org) Received: from freefall.freebsd.org (matteo@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5JHUckV055600; Sun, 19 Jun 2005 17:30:39 GMT (envelope-from matteo@freefall.freebsd.org) Received: (from matteo@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5JHUcEO055596; Sun, 19 Jun 2005 17:30:38 GMT (envelope-from matteo) Date: Sun, 19 Jun 2005 17:30:38 GMT From: Matteo Riondato Message-Id: <200506191730.j5JHUcEO055596@freefall.freebsd.org> To: o@nzym.fi, matteo@FreeBSD.org, freebsd-amd64@FreeBSD.org Cc: Subject: Re: amd64/80839: RELEASE 5.4 / libc: make buildworld fails 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: Sun, 19 Jun 2005 17:30:39 -0000 Synopsis: RELEASE 5.4 / libc: make buildworld fails State-Changed-From-To: analyzed->closed State-Changed-By: matteo State-Changed-When: Sun Jun 19 17:29:47 GMT 2005 State-Changed-Why: Not a bug. Please use the mailing lists for this kind of bugs. http://www.freebsd.org/cgi/query-pr.cgi?pr=80839 From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 19 17:33:37 2005 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 C71B216A41C for ; Sun, 19 Jun 2005 17:33:37 +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 A4A9F43D49 for ; Sun, 19 Jun 2005 17:33:37 +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 j5JHXQr1001394; Sun, 19 Jun 2005 10:33:26 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j5JHXQO4001393; Sun, 19 Jun 2005 10:33:26 -0700 (PDT) (envelope-from sgk) Date: Sun, 19 Jun 2005 10:33:26 -0700 From: Steve Kargl To: "O. Hartmann" Message-ID: <20050619173326.GA1276@troutmask.apl.washington.edu> References: <42B409A7.5020909@mail.uni-mainz.de> <1119099681.759.22.camel@spirit> <42B53F24.8020300@mail.uni-mainz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42B53F24.8020300@mail.uni-mainz.de> User-Agent: Mutt/1.4.2.1i Cc: delphij@delphij.net, freebsd-amd64@freebsd.org Subject: Re: 6.0-Current and gcc 4.x 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: Sun, 19 Jun 2005 17:33:37 -0000 On Sun, Jun 19, 2005 at 11:47:16AM +0200, O. Hartmann wrote: > > Maybe this is a bit of off topic, but I'm curious about why gcc 4.0 let > FreeBSD run into performance penalties. May you give me a hint for > further digging the net? I'm interested in this. GCC 4.0 has an entirely new infrastructure on which optimizations are to be base (ie., tree-ssa). Some of the optimizations available in gcc 3.x are not yet available on 4.0. Others require additional tuning. > Well, the major intention is to use a faster C and/or free Fortran > compiler doing my numerical research on FreeBSD boxes. In most cases I > gained success on compiling Fortran90 code with PGI and/or Intel V8 > compilers, running this code on FBSD 5.3/4 boxes within the Linuxulator. > I found out that some C code performs not that fast as expected using > PGI or Intel C compiler, but Fortran code (F77) performs really faster > (fast in the manner of: it is useable!). > On a pure AMD64-FreeBSD 5.4-STABLE box I feel like a dead man in the > water because I do not have access to a 64Bit Linuxulator using the > 64Bit versions of Intel or PGI (which gave me a real boost on our SuSE > Linux Cluster, but I do not wish to develop under Linux, sorry). You should be able to install gcc 4.0.1 in /usr/local/ and use it for your needs. gfortran, the new Fortran 95 compiler, works on most codes and I use it everyday. There are some bugs in complex modules and derived types, but the gfortran developers are making good progress in killing off bugs. troutmask:kargl[202] uname -m amd64 troutmask:kargl[208] gfortran -v Using built-in specs. Target: amd64-unknown-freebsd6.0 -- Steve From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 19 18:40:18 2005 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 DEEE416A41F for ; Sun, 19 Jun 2005 18:40:18 +0000 (GMT) (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 993A143D4C for ; Sun, 19 Jun 2005 18:40:18 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5JIeILV063632 for ; Sun, 19 Jun 2005 18:40:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5JIeIO5063631; Sun, 19 Jun 2005 18:40:18 GMT (envelope-from gnats) Resent-Date: Sun, 19 Jun 2005 18:40:18 GMT Resent-Message-Id: <200506191840.j5JIeIO5063631@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, Christian Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBB7316A41C for ; Sun, 19 Jun 2005 18:32:38 +0000 (GMT) (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 A71E843D49 for ; Sun, 19 Jun 2005 18:32:38 +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 j5JIWcQW084804 for ; Sun, 19 Jun 2005 18:32:38 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j5JIWc0V084803; Sun, 19 Jun 2005 18:32:38 GMT (envelope-from nobody) Message-Id: <200506191832.j5JIWc0V084803@www.freebsd.org> Date: Sun, 19 Jun 2005 18:32:38 GMT From: Christian To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/82425: fxp0: device timeout, fxp interface dies on 5.4/amd64/smp under load 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: Sun, 19 Jun 2005 18:40:19 -0000 >Number: 82425 >Category: amd64 >Synopsis: fxp0: device timeout, fxp interface dies on 5.4/amd64/smp under load >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jun 19 18:40:18 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Christian >Release: FreeBSD 5.4-STABLE >Organization: >Environment: FreeBSD nox.internal.net 5.4-STABLE FreeBSD 5.4-STABLE #2: Sat Jun 18 22:29:48 BST 2005 root@nox.internal.net:/usr/obj/usr/src/sys/NOX amd64 >Description: With the machine operating as a server under greater than moderate network traffic load, the fxp interface becomes dysfunctional, printing a message "fxp0: device timeout" on the console. While fxp0 is still marked 'up' as per ifconfig, it doesn't tx/rx any traffic at all. The machine also no longer responds to external pings. The problem machine is a dual-Opteron system, running an SMP kernel. >How-To-Repeat: option 1: using the rsync port. Using a second machine, attempt to perform a large rsync to the problem machine. Attempting to send a Maildir mail folder hierarchy with about 318MB in about 36000 files causes fxp0 on the problem machine to die, sometimes only a few dozen files into the rsync. option 2: using nfs. Setup the problem machine as an nfs server, and attempt to copy the above mail directory to the nfs share on the problem machine. fxp0 on the problem machine will die with "fxp0: device timeout". >Fix: no fix known, rebooting the problem machine brings fxp0 back to life. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 19 21:31:22 2005 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 A1A1016A41C for ; Sun, 19 Jun 2005 21:31:22 +0000 (GMT) (envelope-from paul.richards@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F0D943D49 for ; Sun, 19 Jun 2005 21:31:22 +0000 (GMT) (envelope-from paul.richards@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so348024wri for ; Sun, 19 Jun 2005 14:31:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=KZjF4k31EgmxPDrqM7T4uZV1heCyD/0rp+TlXSTHdj91Aw3mlO9oJU8/uQEtOKTBF+e7x8EPLniAh2HbaOrpSjjVDwP8AYqS0wBngWgHih9X7SnH90h5kD532R4kqPd3zTo1WfKCGIF0K+JO+877V2w2MAl1/fdObxfVQ9eHeT8= Received: by 10.54.39.1 with SMTP id m1mr2153961wrm; Sun, 19 Jun 2005 14:31:21 -0700 (PDT) Received: by 10.54.97.7 with HTTP; Sun, 19 Jun 2005 14:31:21 -0700 (PDT) Message-ID: Date: Sun, 19 Jun 2005 22:31:21 +0100 From: Paul Richards To: freebsd-amd64@freebsd.org, freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: Current amd64, "nve0: device timeout" with nForce4 ethernet X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Richards List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2005 21:31:22 -0000 Hi, With CURRENT (checked out earlier this evening) on amd64 I cannot get my nForce4 ethernet adaptor to work. The module automatically loads but I get messages of the form "nve0: device timeout(..)" when I attempt to use the interface. This is exactly the same problem that RELEASE 5.4 had using the nvlan port on my system. I upgraded to current as I was told that the integrated nve driver in 6.0 was more up to date than the nvlan port. Does anyone have nForce4 ethernet working with any version of FreeBSD on amd64? Is this something to do with my particular nForce4 chipset or is the nForce4 ethernet generally unsupported at this time? Thanks, --=20 Paul Richards From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 20 00:23:46 2005 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 4A5C716A41F for ; Mon, 20 Jun 2005 00:23:46 +0000 (GMT) (envelope-from caelian@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0338443D49 for ; Mon, 20 Jun 2005 00:23:45 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by zproxy.gmail.com with SMTP id 18so363876nzp for ; Sun, 19 Jun 2005 17:23:45 -0700 (PDT) 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:content-transfer-encoding:content-disposition:references; b=Sz7vkHgWtjoDmzCgmJsNiu3SJzh9bsE/039GOAXOFaTv6nEVBHmS0emnX88+dCd7FuqJBUmHALR7yn5ZAMXAVATCsgE71OkUcG3ZH133nELStdasrDF0hRIKf6nhaKxpK0pZGm2hCPNG793gO76KVQDsWXdgnW4cQGPDn1JMmy8= Received: by 10.36.96.18 with SMTP id t18mr2686411nzb; Sun, 19 Jun 2005 17:23:45 -0700 (PDT) Received: by 10.36.42.19 with HTTP; Sun, 19 Jun 2005 17:23:45 -0700 (PDT) Message-ID: Date: Sun, 19 Jun 2005 17:23:45 -0700 From: Pascal Hofstee To: Paul Richards In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Current amd64, "nve0: device timeout" with nForce4 ethernet X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pascal Hofstee List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2005 00:23:46 -0000 On 6/19/05, Paul Richards wrote: > Hi, > With CURRENT (checked out earlier this evening) on amd64 I cannot get > my nForce4 ethernet adaptor to work. The module automatically loads > but I get messages of the form "nve0: device timeout(..)" when I > attempt to use the interface. >=20 > This is exactly the same problem that RELEASE 5.4 had using the nvlan > port on my system. I upgraded to current as I was told that the > integrated nve driver in 6.0 was more up to date than the nvlan port. >=20 > Does anyone have nForce4 ethernet working with any version of FreeBSD > on amd64? Is this something to do with my particular nForce4 chipset > or is the nForce4 ethernet generally unsupported at this time? I have a similar problem with my onboard nForce3 based ethernet card. it gets probed/attached just fine ... but drying to actually use the interface gives device timeouts. this is on FreeBSD/amd64 6.0-CURRENT (about 2 days ago) --=20 Pascal Hofstee From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 20 02:21:12 2005 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 A32F016A41F; Mon, 20 Jun 2005 02:21:12 +0000 (GMT) (envelope-from ade@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E10543D5C; Mon, 20 Jun 2005 02:21:12 +0000 (GMT) (envelope-from ade@FreeBSD.org) Received: from freefall.freebsd.org (ade@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5K2LCT8016027; Mon, 20 Jun 2005 02:21:12 GMT (envelope-from ade@freefall.freebsd.org) Received: (from ade@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5K2LCvG016023; Mon, 20 Jun 2005 02:21:12 GMT (envelope-from ade) Date: Mon, 20 Jun 2005 02:21:12 GMT From: Ade Lovett Message-Id: <200506200221.j5K2LCvG016023@freefall.freebsd.org> To: phaceton@gmail.com, ade@FreeBSD.org, freebsd-amd64@FreeBSD.org, ade@FreeBSD.org Cc: Subject: Re: amd64/82422: Stop in /usr/ports/devel/gettext/work/gettext-0.14.5 error 1 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, 20 Jun 2005 02:21:12 -0000 Synopsis: Stop in /usr/ports/devel/gettext/work/gettext-0.14.5 error 1 State-Changed-From-To: open->closed State-Changed-By: ade State-Changed-When: Mon Jun 20 02:18:38 GMT 2005 State-Changed-Why: #1 - if gettext were truly broken, there would be literally thousands of complaints and PRs -- the lack of them would tend to indicate a local problem #2 - woefully inadequate error log output. A single line from portupgrade does not constitute an error report #3 - this is a ports issue, not amd64 - please feel free to resubmit a more detailed problem report, including full logs etc. after you have ensured that everything on your system is appropriately up to date. Responsible-Changed-From-To: freebsd-amd64->ade Responsible-Changed-By: ade Responsible-Changed-When: Mon Jun 20 02:18:38 GMT 2005 Responsible-Changed-Why: gettext maintainer hat. http://www.freebsd.org/cgi/query-pr.cgi?pr=82422 From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 20 07:36:29 2005 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 5468616A41C; Mon, 20 Jun 2005 07:36:29 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id C776643D1F; Mon, 20 Jun 2005 07:36:28 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j5K7WZkv008101; Mon, 20 Jun 2005 09:32:36 +0200 (CEST) (envelope-from sos@FreeBSD.org) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7DBADEEB-4660-4FFF-B4A3-7DDD5A1D525D@FreeBSD.org> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Mon, 20 Jun 2005 09:36:24 +0200 To: Pascal Hofstee X-Mailer: Apple Mail (2.730) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-current@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: Current amd64, "nve0: device timeout" with nForce4 ethernet 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, 20 Jun 2005 07:36:29 -0000 On 20/06/2005, at 2:23, Pascal Hofstee wrote: > On 6/19/05, Paul Richards wrote: > >> Hi, >> With CURRENT (checked out earlier this evening) on amd64 I cannot get >> my nForce4 ethernet adaptor to work. The module automatically loads >> but I get messages of the form "nve0: device timeout(..)" when I >> attempt to use the interface. >> >> This is exactly the same problem that RELEASE 5.4 had using the nvlan >> port on my system. I upgraded to current as I was told that the >> integrated nve driver in 6.0 was more up to date than the nvlan port. >> >> Does anyone have nForce4 ethernet working with any version of FreeBSD >> on amd64? Is this something to do with my particular nForce4 chipset >> or is the nForce4 ethernet generally unsupported at this time? >> > > I have a similar problem with my onboard nForce3 based ethernet card. > it gets probed/attached just fine ... but drying to actually use the > interface gives device timeouts. this is on FreeBSD/amd64 6.0-CURRENT > (about 2 days ago) Ditto here, although it used to work in 100Mbit mode, 1000Mbit mode =20 has always been trouble here. I guess the last round of if_* changes =20 ruined lunch but havn't looked into it yet. - S=F8ren From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 20 08:00:10 2005 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 AA0C516A41C; Mon, 20 Jun 2005 08:00:10 +0000 (GMT) (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 62DEE43D4C; Mon, 20 Jun 2005 08:00:09 +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 ED1611FFACE; Mon, 20 Jun 2005 10:00:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 8E5201FFACD; Mon, 20 Jun 2005 10:00:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 05EEA15652; Mon, 20 Jun 2005 07:57:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id EF5BB15583; Mon, 20 Jun 2005 07:57:29 +0000 (UTC) Date: Mon, 20 Jun 2005 07:57:29 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-Reply-To: <7DBADEEB-4660-4FFF-B4A3-7DDD5A1D525D@FreeBSD.org> Message-ID: References: <7DBADEEB-4660-4FFF-B4A3-7DDD5A1D525D@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-current@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: Current amd64, "nve0: device timeout" with nForce4 ethernet 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, 20 Jun 2005 08:00:10 -0000 On Mon, 20 Jun 2005, S=F8ren Schmidt wrote: > > On 20/06/2005, at 2:23, Pascal Hofstee wrote: > > > On 6/19/05, Paul Richards wrote: > > [ "nve0: device timeout(..)" ] > > > > I have a similar problem with my onboard nForce3 based ethernet card. > > it gets probed/attached just fine ... but drying to actually use the > > interface gives device timeouts. this is on FreeBSD/amd64 6.0-CURRENT > > (about 2 days ago) > > Ditto here, although it used to work in 100Mbit mode, 1000Mbit mode > has always been trouble here. I guess the last round of if_* changes > ruined lunch but havn't looked into it yet. I had and still have trouble with an nf4 on 100Mbit/s before the ifnet changes. The problem is that I only have three Marvell PCIes in that machine so ENOTNET until the nf4 works. I tried to PXE boot with the nf4 and that worked up to the point kernel tried to mount NFS root which gave me above timeout message. Pre-loading an mdimage also worked but it stopped at about 32Mb and thus had been unusable. Don't know if that's a limitation of PXE/loader or another problem. Haven't had the time to build a stripped image. --=20 Bjoern A. Zeeb=09=09=09=09bzeeb at Zabbadoz dot NeT From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 20 08:13:47 2005 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 263EF16A41C; Mon, 20 Jun 2005 08:13:47 +0000 (GMT) (envelope-from nakaji@takamatsu-nct.ac.jp) Received: from www.takamatsu-nct.ac.jp (www.takamatsu-nct.ac.jp [210.137.227.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id E327B43D5C; Mon, 20 Jun 2005 08:13:45 +0000 (GMT) (envelope-from nakaji@takamatsu-nct.ac.jp) Received: from takamatsu-nct.ac.jp (ataka.takamatsu-nct.ac.jp [192.168.17.100]) by www.takamatsu-nct.ac.jp (8.11.6/3.7W) with ESMTP id j5K89KC12847; Mon, 20 Jun 2005 17:09:20 +0900 Received: from roddy.c3922.takamatsu-nct.ac.jp ([192.168.111.25]) by takamatsu-nct.ac.jp (8.11.6/3.7W) with ESMTP id j5K8HWO19017; Mon, 20 Jun 2005 17:17:32 +0900 Received: from roddy.c3922.takamatsu-nct.ac.jp.takamatsu-nct.ac.jp (localhost [IPv6:::1]) by roddy.c3922.takamatsu-nct.ac.jp (8.13.3/8.13.3) with ESMTP id j5K3Ptpb076254; Mon, 20 Jun 2005 12:25:55 +0900 (JST) (envelope-from nakaji@takamatsu-nct.ac.jp) From: NAKAJI Hiroyuki To: freebsd-amd64@FreeBSD.org Organization: Japan FreeBSD User's Group References: <861x70h6g3.fsf@ra333.heimat.gr.jp> <20050619044002.GC46516@dragon.NUXI.org> Date: Mon, 20 Jun 2005 12:25:55 +0900 In-Reply-To: <20050619044002.GC46516@dragon.NUXI.org> (David O'Brien's message of "Sat, 18 Jun 2005 21:40:02 -0700") Message-ID: <8764w9wvy4.fsf@roddy.c3922.takamatsu-nct.ac.jp> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David O'Brien Subject: Re: HDAMD, 39320A-R and U320 disks 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, 20 Jun 2005 08:13:47 -0000 >>>>> In <20050619044002.GC46516@dragon.NUXI.org> >>>>> "David O'Brien" wrote: > On Sat, Jun 18, 2005 at 09:09:00AM +0900, NAKAJI Hiroyuki wrote: > > o Rioworks HDAMD > What BIOS version are you using? The latest one for your revision of > HDAMD? Thanks for the information. I found the latest one at http://www.rioworks.co.jp/bios/files/hdamd/hdamd110.zip and updated. But after I updated, it does not boot any more... This is the next problem (not related to FreeBSD). -- NAKAJI Hiroyuki From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 20 11:01:47 2005 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 E520916A41C for ; Mon, 20 Jun 2005 11:01:46 +0000 (GMT) (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 C9A4E43D53 for ; Mon, 20 Jun 2005 11:01:46 +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.3/8.13.3) with ESMTP id j5KB1kJA011356 for ; Mon, 20 Jun 2005 11:01:46 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5KB1jGa011350 for freebsd-amd64@freebsd.org; Mon, 20 Jun 2005 11:01:45 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 20 Jun 2005 11:01:45 GMT Message-Id: <200506201101.j5KB1jGa011350@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, 20 Jun 2005 11:01:47 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/10/27] amd64/73211 amd64 FAST_IPSEC broken on amd64 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/11/26] amd64/59714 amd64 device timeout and ad0: WARNING - WRITE_D o [2004/07/28] amd64/69704 amd64 ext2/ext3 unstable in amd64 o [2004/07/28] amd64/69707 amd64 IPC32 dont work OK in amd64 FreeBSD o [2004/09/07] amd64/71471 amd64 Can not install 5.3beta3/amd64 on IBM eSe o [2004/10/28] amd64/73252 amd64 ad6: WARNING - READ_DMA interrupt was see o [2004/10/30] amd64/73322 amd64 unarchiving /etc to msdos fs locks up amd o [2004/11/01] amd64/73369 amd64 on-board firewire unreliable with Asus K8 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/04] amd64/77101 amd64 Please include ULi M1689 LAN, SATA, and A o [2005/02/17] amd64/77629 amd64 aMule hardlocks AMD64 system 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 driver on FreeBSD 5.x does not work o 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/19] amd64/81272 amd64 JDK 1.5 port doesn't build. p [2005/05/19] amd64/81279 amd64 /usr/games/random returns every line o [2005/05/20] amd64/81325 amd64 KLD if_ath.ko: depends on ath_hal - not a 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 f [2005/06/12] amd64/82176 amd64 ehci causes crash on amd64 o [2005/06/19] amd64/82425 amd64 fxp0: device timeout, fxp interface dies 33 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/01/11] amd64/61209 amd64 ppc0: cannot reserve I/O port range o [2004/02/21] amd64/63188 amd64 ti(4) broken on amd64 o [2004/07/28] amd64/69705 amd64 IPC problem (msq_queues) o [2004/07/28] amd64/69709 amd64 ACPI enabled then floppy don't work (5.2. o [2004/08/15] amd64/70500 amd64 bge driver for 3Com 3C996B on amd64 preve o [2004/12/02] amd64/74608 amd64 mpt hangs 5 minutes when booting o [2004/12/07] amd64/74811 amd64 df, nfs mount, negative Avail -> 32/64-bi o [2004/12/13] ports/75015 amd64 cvsup on amd64 with runsocks (socks5) cor o [2005/03/17] amd64/78954 amd64 kerberos 5 failed to build o [2005/05/16] amd64/81089 amd64 FreeBSD 5.4 released version can not use o [2005/06/12] amd64/82178 amd64 missing 32bit subsystem o [2005/06/18] amd64/82380 amd64 buildworld error in libc o [2005/06/18] amd64/82399 amd64 MSI K8N Neo4 Platinium is not supported 13 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 20 18:20:50 2005 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 7CACB16A41C for ; Mon, 20 Jun 2005 18:20:50 +0000 (GMT) (envelope-from nakaji@takamatsu-nct.ac.jp) Received: from www.takamatsu-nct.ac.jp (www.takamatsu-nct.ac.jp [210.137.227.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id D48FD43D49 for ; Mon, 20 Jun 2005 18:20:49 +0000 (GMT) (envelope-from nakaji@takamatsu-nct.ac.jp) Received: from takamatsu-nct.ac.jp (ataka.takamatsu-nct.ac.jp [192.168.17.100]) by www.takamatsu-nct.ac.jp (8.11.6/3.7W) with ESMTP id j5KIGKC22210 for ; Tue, 21 Jun 2005 03:16:20 +0900 Received: from roddy.c3922.takamatsu-nct.ac.jp ([192.168.111.25]) by takamatsu-nct.ac.jp (8.11.6/3.7W) with ESMTP id j5KIOWO30226 for ; Tue, 21 Jun 2005 03:24:32 +0900 Received: from roddy.c3922.takamatsu-nct.ac.jp.takamatsu-nct.ac.jp (localhost [IPv6:::1]) by roddy.c3922.takamatsu-nct.ac.jp (8.13.3/8.13.3) with ESMTP id j5K8PodE080785 for ; Mon, 20 Jun 2005 17:25:50 +0900 (JST) (envelope-from nakaji@takamatsu-nct.ac.jp) From: NAKAJI Hiroyuki To: freebsd-amd64@FreeBSD.org References: <861x70h6g3.fsf@ra333.heimat.gr.jp> <20050619044002.GC46516@dragon.NUXI.org> <20050619044002.GC46516@dragon.NUXI.org> <8764w9wvy4.fsf@roddy.c3922.takamatsu-nct.ac.jp> Date: Mon, 20 Jun 2005 17:25:49 +0900 In-Reply-To: <8764w9wvy4.fsf@roddy.c3922.takamatsu-nct.ac.jp> (NAKAJI Hiroyuki's message of "Mon, 20 Jun 2005 12:25:55 +0900") Message-ID: <87d5qh4epe.fsf@roddy.c3922.takamatsu-nct.ac.jp> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: HDAMD, 39320A-R and U320 disks 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, 20 Jun 2005 18:20:50 -0000 >>>>> NAKAJI Hiroyuki wrote: > > > o Rioworks HDAMD > > What BIOS version are you using? The latest one for your revision of > > HDAMD? > Thanks for the information. I found the latest one at > http://www.rioworks.co.jp/bios/files/hdamd/hdamd110.zip > and updated. > But after I updated, it does not boot any more... This is the next > problem (not related to FreeBSD). "CMOS clear" jumper helped me. But my snapshot on 2005/06/16 does not boot to sysinstall. Sorry, no record of boot message. Is 5.4-RELEASE possible to be installed? I'll try it tomorrow. Another note: NetBSD-current on the same day successfully installed with the latest BIOS. -- NAKAJI Hiroyuki From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 21 04:17:59 2005 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 B185F16A41C for ; Tue, 21 Jun 2005 04:17:59 +0000 (GMT) (envelope-from lists@natserv.com) Received: from mail1.acecape.com (mail1.acecape.com [66.114.74.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59F2443D48 for ; Tue, 21 Jun 2005 04:17:59 +0000 (GMT) (envelope-from lists@natserv.com) Received: from zoraida.natserv.net (p65-147.acedsl.com [66.114.65.147]) by mail1.acecape.com (8.12.11/8.12.11) with ESMTP id j5L46CGS030816; Tue, 21 Jun 2005 00:06:58 -0400 Date: Tue, 21 Jun 2005 00:06:12 -0400 (EDT) From: Francisco Reyes X-X-Sender: fran@zoraida.natserv.net To: "Toll, Eric" In-Reply-To: <9BC86C67C3AF7646B9C5382020457A944E4D5C@vip10-win2k.vipstructures.com> Message-ID: <20050621000013.I41554@zoraida.natserv.net> References: <9BC86C67C3AF7646B9C5382020457A944E4D5C@vip10-win2k.vipstructures.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD amd64 List Subject: RE: 3ware cards work in AMD64 port? 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, 21 Jun 2005 04:17:59 -0000 On Thu, 9 Jun 2005, Toll, Eric wrote: > 3ware 9000 Series 3DM2 FreeBSD sources for 64 Bit AMD - 9.2 > release > Filename: 3dm-amd64-bsd-9_2.tgz How do you start it? Ran the install program. Then when I try to connect to the web interface I get: Error loading: http://localhost:88/: Error reading from socket. Besides running the enclosed install was there anything else that needed to be done? Also tried running "3dm2" and got (0x0C:0x0005): Failed to start listening socket However a ps -auxw shows 3dm2 as running ps -auxw | grep 3d root 25819 0.0 0.2 2128 1000 ?? S 12:04AM 0:00.04 3dm2 From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 21 05:01:34 2005 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 8446816A41C for ; Tue, 21 Jun 2005 05:01:34 +0000 (GMT) (envelope-from pmurray@nevada.net.nz) Received: from bellagio.open2view.com (bellagio.open2view.com [203.97.20.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42D7943D48 for ; Tue, 21 Jun 2005 05:01:31 +0000 (GMT) (envelope-from pmurray@nevada.net.nz) Received: from localhost (localhost [127.0.0.1]) by bellagio.open2view.com (Postfix) with ESMTP id 835045B996; Tue, 21 Jun 2005 17:02:09 +1200 (NZST) Received: from bellagio.open2view.com ([127.0.0.1]) by localhost (bellagio.open2view.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69876-08; Tue, 21 Jun 2005 17:02:09 +1200 (NZST) Received: from [10.58.3.145] (222-153-224-129.jetstream.xtra.co.nz [222.153.224.129]) by bellagio.open2view.com (Postfix) with ESMTP id BAD145B989; Tue, 21 Jun 2005 17:02:08 +1200 (NZST) In-Reply-To: <20050621000013.I41554@zoraida.natserv.net> References: <9BC86C67C3AF7646B9C5382020457A944E4D5C@vip10-win2k.vipstructures.com> <20050621000013.I41554@zoraida.natserv.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Murray Date: Tue, 21 Jun 2005 17:01:27 +1200 To: Francisco Reyes X-Mailer: Apple Mail (2.730) X-Virus-Scanned: amavisd-new at open2view.com Cc: freebsd-amd64@freebsd.org Subject: Re: 3ware cards work in AMD64 port? 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, 21 Jun 2005 05:01:34 -0000 On 21/06/2005, at 4:06 PM, Francisco Reyes wrote: > On Thu, 9 Jun 2005, Toll, Eric wrote: > > >> 3ware 9000 Series 3DM2 FreeBSD sources for 64 Bit AMD - 9.2 >> release >> Filename: 3dm-amd64-bsd-9_2.tgz >> > > How do you start it? > Ran the install program. > Then when I try to connect to the web interface I get: > Error loading: http://localhost:88/: Error reading from socket. > It should be port 888, if this wasn't just a typo. Also have a look at the output of sockstat to see if it is actually listening. Cheers Phil Murray From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 21 13:55:06 2005 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 D67C516A41F for ; Tue, 21 Jun 2005 13:55:06 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96F4643D48 for ; Tue, 21 Jun 2005 13:55:06 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j5LDt53U006780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jun 2005 09:55:05 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j5LDt0wC060029; Tue, 21 Jun 2005 09:55:00 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17080.7220.311013.499442@grasshopper.cs.duke.edu> Date: Tue, 21 Jun 2005 09:55:00 -0400 (EDT) To: "O. Hartmann" In-Reply-To: <42B2D638.8090501@mail.uni-mainz.de> References: <42B2D638.8090501@mail.uni-mainz.de> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-amd64@freebsd.org Subject: Re: 6.0-CURRENT (SNAP004) on AMD64 fails, alternatives? 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, 21 Jun 2005 13:55:07 -0000 O. Hartmann writes: > Hello. > I try to boot 6.0-Current from the most recent June2005 snap built and > kernel fails due to detaching and ataching hard drives connected to the > nForce4 SATA controller (ASUS A8N-SLI Deluxe with Maxtor 6MO200B and > Samsung 2004C drives). > > I read about problems with SATA/ATA in this list so I don't want to do a > error report. I would like to know whether there is an alternative way > to get a maybe fixed boot image of 6.0-CURRENT? What I did was to build a -current kernel on another machine, and netboot that via PXE (my motherboard calls it the "Nvidia Boot Agent") Make sure that you copy the mfsroot.gz from the CDROM into your diskless boot area, and put this into the loader.conf in your diskless boot area: mfsroot_load="YES" mfsroot_type="mfs_root" mfsroot_name="/boot/mfsroot" vfs.root.mountfrom="ufs:/dev/md0c" Make sure to go to the shell prompt and copy the good kernel onto the machine after the installation, but before rebooting. To do this, you'll need a network. I had problems with the nve0 adapter (though PXE worked great), and ended up switching to the sk0 adapter. This is annoying, because linux & solaris hate the sk0 adapter and like the nforce ethernet better.. Good luck! Drew From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 21 18:20:36 2005 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 EFB9916A41C for ; Tue, 21 Jun 2005 18:20:36 +0000 (GMT) (envelope-from ghelmer@palisadesys.com) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC04143D1D for ; Tue, 21 Jun 2005 18:20:36 +0000 (GMT) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.1.108] (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0) by magellan.palisadesys.com (8.12.11/8.12.11) with ESMTP id j5LIKW0r086600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Jun 2005 13:20:32 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Message-ID: <42B85A70.3070108@palisadesys.com> Date: Tue, 21 Jun 2005 13:20:32 -0500 From: Guy Helmer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-MailScanner-From: ghelmer@palisadesys.com Subject: mmap(2) length argument limits 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, 21 Jun 2005 18:20:37 -0000 Is mmap(2) truly limited to mapping 2GB chunks of a file, even on 64-bit platforms where a 64-bit offset in the VM system shouldn't be such a performance penalty, or does the BUGS section of the mmap(2) man page apply to 32-bit platforms only? TIA, Guy Helmer From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 21 20:00:28 2005 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 81A9416A41C; Tue, 21 Jun 2005 20:00:28 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40B5443D58; Tue, 21 Jun 2005 20:00:28 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j5LK0R78005729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jun 2005 16:00:27 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j5LK0Ml1060482; Tue, 21 Jun 2005 16:00:22 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17080.29141.918333.170950@grasshopper.cs.duke.edu> Date: Tue, 21 Jun 2005 16:00:21 -0400 (EDT) To: John Baldwin In-Reply-To: <200506171434.49008.jhb@FreeBSD.org> References: <20050510223636.GA49927@xor.obsecurity.org> <20050529175056.GA99318@xor.obsecurity.org> <200506171434.49008.jhb@FreeBSD.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: amd64@FreeBSD.org, current@FreeBSD.org, Kris Kennaway Subject: Re: Fatal trap 12 in exec_copyout_strings() 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, 21 Jun 2005 20:00:28 -0000 John Baldwin writes: > On Sunday 29 May 2005 01:50 pm, Kris Kennaway wrote: > > On Tue, May 10, 2005 at 03:36:36PM -0700, Kris Kennaway wrote: > > > Got this on a dual amd64 with 8GB RAM running 6.0 from last week: > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 1; apic id = 01 > > > fault virtual address = 0xffffffffa9cdc000 > > > fault code = supervisor read, page not present > > > instruction pointer = 0x8:0xffffffff8037759f > > > stack pointer = 0x10:0xffffffffba1637d0 > > > frame pointer = 0x10:0xffffffffba163820 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 52247 (sh) > > > [thread pid 52247 tid 100149 ] > > > Stopped at exec_copyout_strings+0x12f: > > > db> wh > > > Tracing pid 52247 tid 100149 td 0xffffff016e5724c0 > > > exec_copyout_strings() at exec_copyout_strings+0x12f > > > do_execve() at do_execve+0x39a > > > kern_execve() at kern_execve+0xab > > > execve() at execve+0x49 > > > syscall() at syscall+0x382 > > > Xfast_syscall() at Xfast_syscall+0xa8 > > > --- syscall (59, FreeBSD ELF64, execve), rip = 0x80090622c, rsp = > > > 0x7fffffffe058, rbp = 0xffffffff --- db> > > > > I've got this panic twice more since. > > Do you have a kernel.debug? Can you do 'list *exec_copyout_strings+0x12f'? I > think I've seen reports of the linux32_exec_copyout_strings() having a > similar fault as well on amd64. I just got this on my freshly installed UP, 512MB athlon64. For me, its 100% reproducable when running a cross-compiler built on FreeBSD-4. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xffffffff90ba3000 fault code = supervisor read, page not present instruction pointer = 0x8:0xffffffff80412c20 stack pointer = 0x10:0xffffffff9666b730 frame pointer = 0x10:0xffffffff9666b770 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2095 (lanai-gcc) [thread pid 2095 tid 100077 ] Stopped at ia32_copyout_strings+0x110: Even after compiling with -O -pipe -g, GDB's stack trace is not so great: #0 doadump () at pcpu.h:172 #1 0xffffffff801877a3 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0x0) at ../../../ddb/db_command.c:531 #2 0xffffffff801874f0 in db_command (last_cmdp=0xffffffff805caee8, cmd_table=0x0, aux_cmd_tablep=0xffffffff80475ab0, aux_cmd_tablep_end=0xffffffff80475ab8) at ../../../ddb/db_command.c:349 #3 0xffffffff80187617 in db_command_loop () at ../../../ddb/db_command.c:455 #4 0xffffffff801897a5 in db_trap (type=-1771653920, code=0) at ../../../ddb/db_main.c:221 #5 0xffffffff802a87fd in kdb_trap (type=12, code=0, tf=0xffffffff9666b680) at ../../../kern/subr_kdb.c:471 #6 0xffffffff803df595 in trap_fatal (frame=0xffffffff9666b680, eva=18446744071842705408) at ../../../amd64/amd64/trap.c:650 #7 0xffffffff803df232 in trap_pfault (frame=0xffffffff9666b680, usermode=0) at ../../../amd64/amd64/trap.c:578 #8 0xffffffff803dee6a in trap (frame= {tf_rdi = 4294956412, tf_rsi = 4294956816, tf_rdx = -1771651824, tf_rcx = -1771651824, tf_r8 = 64, tf_r9 = 0, tf_rax = 0, tf_rbx = -1866846208, tf_rbp = -1771653264, tf_r10 = -1099156726496, tf_r11 = 264314796, tf_r12 = 4294956816, tf_r13 = 4294956416, tf_r14 = 23, tf_r15 = 46, tf_trapno = 12, tf_addr = -1866846208, tf_flags = -2143426697, tf_err = 0, tf_rip = -2143212512, tf_cs = 8, tf_rflags = 66118, tf_rsp = -1771653312, tf_ss = 16}) at ../../../amd64/amd64/trap.c:357 #9 0xffffffff803cdb8b in calltrap () at ../../../amd64/amd64/exception.S:172 ---Type to continue, or q to quit--- #10 0x00000000ffffd57c in ?? () #11 0x00000000ffffd710 in ?? () #12 0xffffffff9666bd10 in ?? () #13 0xffffffff9666bd10 in ?? () #14 0x0000000000000040 in ?? () #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0xffffffff90ba3000 in ?? () #18 0xffffffff9666b770 in ?? () #19 0xffffff0015275d20 in ?? () #20 0x000000000fc11fac in ?? () #21 0x00000000ffffd710 in ?? () #22 0x00000000ffffd580 in ?? () #23 0x0000000000000017 in ?? () #24 0x000000000000002e in ?? () #25 0x000000000000000c in ?? () #26 0xffffffff90ba3000 in ?? () #27 0xffffffff803de777 in suword32 () at ../../../amd64/amd64/support.S:452 #28 0x0000000000000000 in ?? () #29 0xffffffff80412c20 in ia32_copyout_strings (imgp=0xffffffff90ba3000) at ../../../compat/ia32/ia32_sysvec.c:245 #30 0xffffffff8026b9c2 in do_execve (td=0xffffff00186ca980, args=0x0, mac_p=0x0) at ../../../kern/kern_exec.c:452 #31 0xffffffff8026b52e in kern_execve (td=0xffffff00186ca980, args=0xffffffff9666bb10, mac_p=0x0) at ../../../kern/kern_exec.c:250 #32 0xffffffff80411859 in freebsd32_execve (td=0xffffff00186ca980, uap=0x0) at ../../../compat/freebsd32/freebsd32_misc.c:321 #33 0xffffffff80411047 in ia32_syscall (frame= {tf_rdi = 0, tf_rsi = 0, tf_rdx = 1, tf_rcx = 134563369, tf_r8 = 0, tf_r9 = 0, tf_rax = 59, tf_rbx = 672188772, tf_rbp = 4294955352, tf_r10 = 0, tf_r11 = 0, tf_r12 = 0, tf_r13 = 0, tf_r14 = 0, tf_r15 = 0, tf_trapno = 0, tf_addr = 0, tf_flags = 12, tf_err = 2, tf_rip = 671876628, tf_cs = 27, tf_rflags = 647, tf_rsp = 4294955308, tf_ss = 35}) at ../../../amd64/ia32/ia32_syscall.c:186 #34 0xffffffff803cddfd in Xint0x80_syscall () at ia32_exception.S:64 The line number gdb says the crash happened on does not correspond to what ddb says. (kgdb) frame 29 #29 0xffffffff80412c20 in ia32_copyout_strings (imgp=0xffffffff90ba3000) at ../../../compat/ia32/ia32_sysvec.c:245 245 suword32(vectp++, (u_int32_t)(intptr_t)destp); vs: (kgdb) l *0xffffffff80412c20 0xffffffff80412c20 is in ia32_copyout_strings (../../../compat/ia32/ia32_sysvec.c:247). 242 * Fill in argument portion of vector table. 243 */ 244 for (; argc > 0; --argc) { 245 suword32(vectp++, (u_int32_t)(intptr_t)destp); 246 while (*stringp++ != 0) 247 destp++; 248 destp++; 249 } 250 251 /* a null vector table pointer separates the argp's from the envp's */ The deref of stringp makes sense, as it corresponds to the faulting address reported in ddb: (kgdb) p stringp $27 = 0xffffffff90ba3000
(kgdb) p *imgp->args $33 = { buf = 0xffffffff90ba3000
, begin_argv = 0xffffffff90ba3000
, begin_envv = 0xffffffff90ba313d
, endp = 0xffffffff90ba389f
, fname = 0xffffffff90be3000 "/home/gallatin/lanaitools/intel_FreeBSD/lib/gcc-lib/lanai/2.95.2..1.6/cc1", stringspace = 259937, argc = 23, envc = 46 } I'm puzzled. fname seems to be buf+ARGV_MAX, so its not like something randomly scribbled on this memory. In the debugger, the memory just below buf+ARGV_MAX seems to be unmapped. But we've done copyins in freebsd32_exec_copyin_args(), otherwise endp would not have been advanced. So we've written to this memory. It is almost like somebody freed buf through buf + 262144. Drew From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 14:31:37 2005 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 8B9A016A41C; Wed, 22 Jun 2005 14:31:37 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BA1543D58; Wed, 22 Jun 2005 14:31:37 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 22 Jun 2005 10:44:50 -0400 From: John Baldwin To: freebsd-amd64@freebsd.org Date: Wed, 22 Jun 2005 10:31:54 -0400 User-Agent: KMail/1.8 References: <20050510223636.GA49927@xor.obsecurity.org> <200506171434.49008.jhb@FreeBSD.org> <17080.29141.918333.170950@grasshopper.cs.duke.edu> In-Reply-To: <17080.29141.918333.170950@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506221031.55875.jhb@FreeBSD.org> Cc: sobomax@FreeBSD.org, Kris Kennaway , Andrew Gallatin , current@freebsd.org Subject: Re: Fatal trap 12 in exec_copyout_strings() 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, 22 Jun 2005 14:31:37 -0000 On Tuesday 21 June 2005 04:00 pm, Andrew Gallatin wrote: > John Baldwin writes: > > On Sunday 29 May 2005 01:50 pm, Kris Kennaway wrote: > > > On Tue, May 10, 2005 at 03:36:36PM -0700, Kris Kennaway wrote: > > > > Got this on a dual amd64 with 8GB RAM running 6.0 from last week: > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > cpuid = 1; apic id = 01 > > > > fault virtual address = 0xffffffffa9cdc000 > > > > fault code = supervisor read, page not present > > > > instruction pointer = 0x8:0xffffffff8037759f > > > > stack pointer = 0x10:0xffffffffba1637d0 > > > > frame pointer = 0x10:0xffffffffba163820 > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > current process = 52247 (sh) > > > > [thread pid 52247 tid 100149 ] > > > > Stopped at exec_copyout_strings+0x12f: > > > > db> wh > > > > Tracing pid 52247 tid 100149 td 0xffffff016e5724c0 > > > > exec_copyout_strings() at exec_copyout_strings+0x12f > > > > do_execve() at do_execve+0x39a > > > > kern_execve() at kern_execve+0xab > > > > execve() at execve+0x49 > > > > syscall() at syscall+0x382 > > > > Xfast_syscall() at Xfast_syscall+0xa8 > > > > --- syscall (59, FreeBSD ELF64, execve), rip = 0x80090622c, rsp = > > > > 0x7fffffffe058, rbp = 0xffffffff --- db> > > > > > > I've got this panic twice more since. > > > > Do you have a kernel.debug? Can you do 'list > > *exec_copyout_strings+0x12f'? I think I've seen reports of the > > linux32_exec_copyout_strings() having a similar fault as well on amd64. > > I just got this on my freshly installed UP, 512MB athlon64. For me, > its 100% reproducable when running a cross-compiler built on > FreeBSD-4. > > (kgdb) p *imgp->args > $33 = { > buf = 0xffffffff90ba3000
, > begin_argv = 0xffffffff90ba3000
bounds>, begin_envv = 0xffffffff90ba313d
bounds>, endp = 0xffffffff90ba389f
bounds>, fname = 0xffffffff90be3000 > "/home/gallatin/lanaitools/intel_FreeBSD/lib/gcc-lib/lanai/2.95.2..1.6/cc1" >, stringspace = 259937, > argc = 23, > envc = 46 > } > > I'm puzzled. fname seems to be buf+ARGV_MAX, so its not > like something randomly scribbled on this memory. > > In the debugger, the memory just below buf+ARGV_MAX seems to be > unmapped. But we've done copyins in freebsd32_exec_copyin_args(), > otherwise endp would not have been advanced. So we've written to this > memory. > > It is almost like somebody freed buf through buf + 262144. I think I figured it out. sobomax@ changed how much memory exec_copyin_args() and exec_free_args() allocated and freed without updating freebsd32_exec_copyin_args() and linux_exec_copyin_args(), so more memory was freed than was allocated which would free memory out from other execs. Patch is below. Let me know if it fixes the problem. Index: amd64/linux32/linux32_machdep.c =================================================================== RCS file: /usr/cvs/src/sys/amd64/linux32/linux32_machdep.c,v retrieving revision 1.9 diff -u -r1.9 linux32_machdep.c --- amd64/linux32/linux32_machdep.c 5 Apr 2005 15:28:06 -0000 1.9 +++ amd64/linux32/linux32_machdep.c 22 Jun 2005 14:26:03 -0000 @@ -113,7 +113,8 @@ * Allocate temporary demand zeroed space for argument and * environment strings */ - args->buf = (char *) kmem_alloc_wait(exec_map, PATH_MAX + ARG_MAX); + args->buf = (char *) kmem_alloc_wait(exec_map, + PATH_MAX + ARG_MAX + MAXSHELLCMDLEN); if (args->buf == NULL) return (ENOMEM); args->begin_argv = args->buf; Index: compat/freebsd32/freebsd32_misc.c =================================================================== RCS file: /usr/cvs/src/sys/compat/freebsd32/freebsd32_misc.c,v retrieving revision 1.35 diff -u -r1.35 freebsd32_misc.c --- compat/freebsd32/freebsd32_misc.c 11 Jun 2005 14:58:20 -0000 1.35 +++ compat/freebsd32/freebsd32_misc.c 22 Jun 2005 14:26:11 -0000 @@ -237,7 +237,8 @@ * Allocate temporary demand zeroed space for argument and * environment strings */ - args->buf = (char *) kmem_alloc_wait(exec_map, PATH_MAX + ARG_MAX); + args->buf = (char *) kmem_alloc_wait(exec_map, + PATH_MAX + ARG_MAX + MAXSHELLCMDLEN); if (args->buf == NULL) return (ENOMEM); args->begin_argv = args->buf; -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 15:28:28 2005 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 653B716A41C; Wed, 22 Jun 2005 15:28:28 +0000 (GMT) (envelope-from pbacklun@cc.hut.fi) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBC3B43D1F; Wed, 22 Jun 2005 15:28:27 +0000 (GMT) (envelope-from pbacklun@cc.hut.fi) Received: from [85.76.71.80] (ZMCCLXXIX.dsl.saunalahti.fi [85.76.71.80]) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 342C8C2BE4; Wed, 22 Jun 2005 18:28:26 +0300 (EEST) Message-ID: <42B9839A.4060006@cc.hut.fi> Date: Wed, 22 Jun 2005 18:28:26 +0300 From: Patrik Backlund User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050507) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20050510223636.GA49927@xor.obsecurity.org> <200506171434.49008.jhb@FreeBSD.org> <17080.29141.918333.170950@grasshopper.cs.duke.edu> <200506221031.55875.jhb@FreeBSD.org> In-Reply-To: <200506221031.55875.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, sobomax@freebsd.org, Andrew Gallatin , freebsd-amd64@freebsd.org, Kris Kennaway Subject: Re: Fatal trap 12 in exec_copyout_strings() 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, 22 Jun 2005 15:28:28 -0000 John Baldwin wrote: > On Tuesday 21 June 2005 04:00 pm, Andrew Gallatin wrote: > >>John Baldwin writes: >> > On Sunday 29 May 2005 01:50 pm, Kris Kennaway wrote: >> > > On Tue, May 10, 2005 at 03:36:36PM -0700, Kris Kennaway wrote: >> > > > Got this on a dual amd64 with 8GB RAM running 6.0 from last week: >> > > > >> > > > Fatal trap 12: page fault while in kernel mode >> > > > cpuid = 1; apic id = 01 >> > > > fault virtual address = 0xffffffffa9cdc000 >> > > > fault code = supervisor read, page not present >> > > > instruction pointer = 0x8:0xffffffff8037759f >> > > > stack pointer = 0x10:0xffffffffba1637d0 >> > > > frame pointer = 0x10:0xffffffffba163820 >> > > > code segment = base 0x0, limit 0xfffff, type 0x1b >> > > > = DPL 0, pres 1, long 1, def32 0, gran 1 >> > > > processor eflags = interrupt enabled, resume, IOPL = 0 >> > > > current process = 52247 (sh) >> > > > [thread pid 52247 tid 100149 ] >> > > > Stopped at exec_copyout_strings+0x12f: >> > > > db> wh >> > > > Tracing pid 52247 tid 100149 td 0xffffff016e5724c0 >> > > > exec_copyout_strings() at exec_copyout_strings+0x12f >> > > > do_execve() at do_execve+0x39a >> > > > kern_execve() at kern_execve+0xab >> > > > execve() at execve+0x49 >> > > > syscall() at syscall+0x382 >> > > > Xfast_syscall() at Xfast_syscall+0xa8 >> > > > --- syscall (59, FreeBSD ELF64, execve), rip = 0x80090622c, rsp = >> > > > 0x7fffffffe058, rbp = 0xffffffff --- db> >> > > >> > > I've got this panic twice more since. >> > >> > Do you have a kernel.debug? Can you do 'list >> > *exec_copyout_strings+0x12f'? I think I've seen reports of the >> > linux32_exec_copyout_strings() having a similar fault as well on amd64. >> >>I just got this on my freshly installed UP, 512MB athlon64. For me, >>its 100% reproducable when running a cross-compiler built on >>FreeBSD-4. >> >>(kgdb) p *imgp->args >>$33 = { >> buf = 0xffffffff90ba3000
, >> begin_argv = 0xffffffff90ba3000
>bounds>, begin_envv = 0xffffffff90ba313d
>bounds>, endp = 0xffffffff90ba389f
>bounds>, fname = 0xffffffff90be3000 >>"/home/gallatin/lanaitools/intel_FreeBSD/lib/gcc-lib/lanai/2.95.2..1.6/cc1" >>, stringspace = 259937, >> argc = 23, >> envc = 46 >>} >> >>I'm puzzled. fname seems to be buf+ARGV_MAX, so its not >>like something randomly scribbled on this memory. >> >>In the debugger, the memory just below buf+ARGV_MAX seems to be >>unmapped. But we've done copyins in freebsd32_exec_copyin_args(), >>otherwise endp would not have been advanced. So we've written to this >>memory. >> >>It is almost like somebody freed buf through buf + 262144. > > > I think I figured it out. sobomax@ changed how much memory exec_copyin_args() > and exec_free_args() allocated and freed without updating > freebsd32_exec_copyin_args() and linux_exec_copyin_args(), so more memory was > freed than was allocated which would free memory out from other execs. Patch > is below. Let me know if it fixes the problem. YES! In May I reported a very similar reproducable panic in linux32_exec_copyout_strings and this patches fixes the problem for me. I can now use skype in current again. Thanks! BR, Patrik From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 15:32:05 2005 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 A26E116A41C; Wed, 22 Jun 2005 15:32:05 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2957243D1D; Wed, 22 Jun 2005 15:32:04 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.49] (lesnik.portaone.com [195.140.246.50]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j5MFVsFH076970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jun 2005 17:31:55 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <42B98469.7060505@portaone.com> Date: Wed, 22 Jun 2005 18:31:53 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20050510223636.GA49927@xor.obsecurity.org> <200506171434.49008.jhb@FreeBSD.org> <17080.29141.918333.170950@grasshopper.cs.duke.edu> <200506221031.55875.jhb@FreeBSD.org> In-Reply-To: <200506221031.55875.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/951/Wed Jun 22 15:28:13 2005 on www.portaone.com X-Virus-Status: Clean Cc: sobomax@FreeBSD.ORG, Kris Kennaway , Andrew Gallatin , freebsd-amd64@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Fatal trap 12 in exec_copyout_strings() X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim.Sobolev@portaone.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2005 15:32:05 -0000 Good catch! Sorry for missing it. -Maxim John Baldwin wrote: > On Tuesday 21 June 2005 04:00 pm, Andrew Gallatin wrote: > >>John Baldwin writes: >> > On Sunday 29 May 2005 01:50 pm, Kris Kennaway wrote: >> > > On Tue, May 10, 2005 at 03:36:36PM -0700, Kris Kennaway wrote: >> > > > Got this on a dual amd64 with 8GB RAM running 6.0 from last week: >> > > > >> > > > Fatal trap 12: page fault while in kernel mode >> > > > cpuid = 1; apic id = 01 >> > > > fault virtual address = 0xffffffffa9cdc000 >> > > > fault code = supervisor read, page not present >> > > > instruction pointer = 0x8:0xffffffff8037759f >> > > > stack pointer = 0x10:0xffffffffba1637d0 >> > > > frame pointer = 0x10:0xffffffffba163820 >> > > > code segment = base 0x0, limit 0xfffff, type 0x1b >> > > > = DPL 0, pres 1, long 1, def32 0, gran 1 >> > > > processor eflags = interrupt enabled, resume, IOPL = 0 >> > > > current process = 52247 (sh) >> > > > [thread pid 52247 tid 100149 ] >> > > > Stopped at exec_copyout_strings+0x12f: >> > > > db> wh >> > > > Tracing pid 52247 tid 100149 td 0xffffff016e5724c0 >> > > > exec_copyout_strings() at exec_copyout_strings+0x12f >> > > > do_execve() at do_execve+0x39a >> > > > kern_execve() at kern_execve+0xab >> > > > execve() at execve+0x49 >> > > > syscall() at syscall+0x382 >> > > > Xfast_syscall() at Xfast_syscall+0xa8 >> > > > --- syscall (59, FreeBSD ELF64, execve), rip = 0x80090622c, rsp = >> > > > 0x7fffffffe058, rbp = 0xffffffff --- db> >> > > >> > > I've got this panic twice more since. >> > >> > Do you have a kernel.debug? Can you do 'list >> > *exec_copyout_strings+0x12f'? I think I've seen reports of the >> > linux32_exec_copyout_strings() having a similar fault as well on amd64. >> >>I just got this on my freshly installed UP, 512MB athlon64. For me, >>its 100% reproducable when running a cross-compiler built on >>FreeBSD-4. >> >>(kgdb) p *imgp->args >>$33 = { >> buf = 0xffffffff90ba3000
, >> begin_argv = 0xffffffff90ba3000
>bounds>, begin_envv = 0xffffffff90ba313d
>bounds>, endp = 0xffffffff90ba389f
>bounds>, fname = 0xffffffff90be3000 >>"/home/gallatin/lanaitools/intel_FreeBSD/lib/gcc-lib/lanai/2.95.2..1.6/cc1" >>, stringspace = 259937, >> argc = 23, >> envc = 46 >>} >> >>I'm puzzled. fname seems to be buf+ARGV_MAX, so its not >>like something randomly scribbled on this memory. >> >>In the debugger, the memory just below buf+ARGV_MAX seems to be >>unmapped. But we've done copyins in freebsd32_exec_copyin_args(), >>otherwise endp would not have been advanced. So we've written to this >>memory. >> >>It is almost like somebody freed buf through buf + 262144. > > > I think I figured it out. sobomax@ changed how much memory exec_copyin_args() > and exec_free_args() allocated and freed without updating > freebsd32_exec_copyin_args() and linux_exec_copyin_args(), so more memory was > freed than was allocated which would free memory out from other execs. Patch > is below. Let me know if it fixes the problem. > > Index: amd64/linux32/linux32_machdep.c > =================================================================== > RCS file: /usr/cvs/src/sys/amd64/linux32/linux32_machdep.c,v > retrieving revision 1.9 > diff -u -r1.9 linux32_machdep.c > --- amd64/linux32/linux32_machdep.c 5 Apr 2005 15:28:06 -0000 1.9 > +++ amd64/linux32/linux32_machdep.c 22 Jun 2005 14:26:03 -0000 > @@ -113,7 +113,8 @@ > * Allocate temporary demand zeroed space for argument and > * environment strings > */ > - args->buf = (char *) kmem_alloc_wait(exec_map, PATH_MAX + ARG_MAX); > + args->buf = (char *) kmem_alloc_wait(exec_map, > + PATH_MAX + ARG_MAX + MAXSHELLCMDLEN); > if (args->buf == NULL) > return (ENOMEM); > args->begin_argv = args->buf; > Index: compat/freebsd32/freebsd32_misc.c > =================================================================== > RCS file: /usr/cvs/src/sys/compat/freebsd32/freebsd32_misc.c,v > retrieving revision 1.35 > diff -u -r1.35 freebsd32_misc.c > --- compat/freebsd32/freebsd32_misc.c 11 Jun 2005 14:58:20 -0000 1.35 > +++ compat/freebsd32/freebsd32_misc.c 22 Jun 2005 14:26:11 -0000 > @@ -237,7 +237,8 @@ > * Allocate temporary demand zeroed space for argument and > * environment strings > */ > - args->buf = (char *) kmem_alloc_wait(exec_map, PATH_MAX + ARG_MAX); > + args->buf = (char *) kmem_alloc_wait(exec_map, > + PATH_MAX + ARG_MAX + MAXSHELLCMDLEN); > if (args->buf == NULL) > return (ENOMEM); > args->begin_argv = args->buf; > From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 15:33:14 2005 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 ADBC916A41C; Wed, 22 Jun 2005 15:33:14 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B31443D49; Wed, 22 Jun 2005 15:33:14 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j5MFXDqC008872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jun 2005 11:33:13 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j5MFX8T3061800; Wed, 22 Jun 2005 11:33:08 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17081.33972.316494.40649@grasshopper.cs.duke.edu> Date: Wed, 22 Jun 2005 11:33:08 -0400 (EDT) To: John Baldwin In-Reply-To: <200506221031.55875.jhb@FreeBSD.org> References: <20050510223636.GA49927@xor.obsecurity.org> <200506171434.49008.jhb@FreeBSD.org> <17080.29141.918333.170950@grasshopper.cs.duke.edu> <200506221031.55875.jhb@FreeBSD.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: sobomax@FreeBSD.org, current@FreeBSD.org, freebsd-amd64@FreeBSD.org, Kris Kennaway Subject: Re: Fatal trap 12 in exec_copyout_strings() 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, 22 Jun 2005 15:33:14 -0000 John Baldwin writes: > > I think I figured it out. sobomax@ changed how much memory exec_copyin_args() > and exec_free_args() allocated and freed without updating > freebsd32_exec_copyin_args() and linux_exec_copyin_args(), so more memory was > freed than was allocated which would free memory out from other execs. Patch > is below. Let me know if it fixes the problem. > This works for me. Previously, running the cross compiler would panic the box instantly. Now it works fine. Your theory about freeing things from other execs makes sense because gcc is always exec'ing off different stages of the compilation.. Nice work! Drew From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 17:41:57 2005 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 B6D1816A432 for ; Wed, 22 Jun 2005 17:41:57 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8721943D1D for ; Wed, 22 Jun 2005 17:41:57 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 2CB51970D7; Wed, 22 Jun 2005 10:41:48 -0700 (PDT) Message-Id: <3.0.1.32.20050622104159.00a55450@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Wed, 22 Jun 2005 10:41:59 -0700 To: freebsd-amd64@FreeBSD.org From: ray@redshift.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Subject: Slower MySQL inserts for AMD64/Opteron? 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, 22 Jun 2005 17:41:58 -0000 I did some benchmarks recently on a single 2.4Ghz Xeon against a Dual 246 Opteron and noticed when it came to MySQL inserts, the single Xeon was about 20% faster on inserts (and it actually had a slower hard drive, IDE vs SATA). The interesting thing is that the Dual Opterons was twice as fast retrieving the data using selects. Does anyone have any ideas as to why the single Xeon would beat it on inserts? I've seen other benchmarks floating around (e.g. Tom's hardware guide) that seems to mirror the results I found. I also spoke to AMD about it and they only suggestion was to try running i386 on the AMD, as opposed to AMD64. They also mentioned something about perhaps compiler switches, but so far I haven't heard back, nor have I had a chance to test further. The Xeon was running 5.3/i386. I believe the AMD was running 5.4/AMD64. If anyone has any ideas as to what might be the cause, I would be interested in hearing. I'm getting ready to load i386 on the AMD (using a spare drive) just to see if this makes a difference. Am I over looking something that is required to unlock the power of the AMD? The selects being twice as fast was great, but then again the AMD has two CPU's also. Thanks! Ray From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 17:51:52 2005 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 2C2E516A41C for ; Wed, 22 Jun 2005 17:51:52 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC4F743D48 for ; Wed, 22 Jun 2005 17:51:51 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from stevenp4 ([193.123.241.40]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.0.2.R) with ESMTP id md50001548097.msg for ; Wed, 22 Jun 2005 18:46:04 +0100 Message-ID: <0b2601c57753$0a0a8660$7f06000a@int.mediasurface.com> From: "Steven Hartland" To: , References: <3.0.1.32.20050622104159.00a55450@pop.redshift.com> Date: Wed, 22 Jun 2005 18:51:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Wed, 22 Jun 2005 18:46:04 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 193.123.241.40 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-amd64@FreeBSD.org X-MDAV-Processed: multiplay.co.uk, Wed, 22 Jun 2005 18:46:04 +0100 Cc: Subject: Re: Slower MySQL inserts for AMD64/Opteron? 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, 22 Jun 2005 17:51:52 -0000 Too many variables there too draw any conclusions from the comparison. Compare like for like. Steve / K ----- Original Message ----- From: >I did some benchmarks recently on a single 2.4Ghz Xeon against a Dual 246 > Opteron and noticed when it came to MySQL inserts, the single Xeon was about 20% > faster on inserts (and it actually had a slower hard drive, IDE vs SATA). The > interesting thing is that the Dual Opterons was twice as fast retrieving the > data using selects. > > Does anyone have any ideas as to why the single Xeon would beat it on inserts? > I've seen other benchmarks floating around (e.g. Tom's hardware guide) that > seems to mirror the results I found. I also spoke to AMD about it and they only > suggestion was to try running i386 on the AMD, as opposed to AMD64. They also > mentioned something about perhaps compiler switches, but so far I haven't heard > back, nor have I had a chance to test further. > > The Xeon was running 5.3/i386. I believe the AMD was running 5.4/AMD64. > > If anyone has any ideas as to what might be the cause, I would be interested in > hearing. I'm getting ready to load i386 on the AMD (using a spare drive) just > to see if this makes a difference. Am I over looking something that is required > to unlock the power of the AMD? The selects being twice as fast was great, but > then again the AMD has two CPU's also. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 22:16:40 2005 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 3E3E016A41C for ; Wed, 22 Jun 2005 22:16:40 +0000 (GMT) (envelope-from vkushnir@i.kiev.ua) Received: from horse.iptelecom.net.ua (horse.iptelecom.net.ua [212.9.224.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62D2343D1D for ; Wed, 22 Jun 2005 22:16:39 +0000 (GMT) (envelope-from vkushnir@i.kiev.ua) Received: from h148.240.159.dialup.iptcom.net ([213.159.240.148]:39621 "EHLO kushnir1.kiev.ua" ident: "SOCKFAULT1" whoson: "vkushnir") by horse.iptelecom.net.ua with ESMTP id S1219399AbVFVWQh (INRCPT ); Thu, 23 Jun 2005 01:16:37 +0300 Received: from kushnir1.kiev.ua (kushnir1.kiev.ua [10.0.0.1]) by kushnir1.kiev.ua (8.13.4/8.13.3) with ESMTP id j5MMGXOW004607 for ; Thu, 23 Jun 2005 01:16:33 +0300 (EEST) (envelope-from vkushnir@i.kiev.ua) Date: Thu, 23 Jun 2005 01:16:33 +0300 (EEST) From: Vladimir Kushnir X-X-Sender: vkushnir@kushnir1.kiev.ua To: freebsd-amd64@freebsd.org In-Reply-To: <20050614000247.X30515@kushnir1.kiev.ua> Message-ID: <20050623011049.R3714@kushnir1.kiev.ua> References: <20050614000247.X30515@kushnir1.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: SOLVED: nForce4 + PCIE Radeons - anybody? 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, 22 Jun 2005 22:16:40 -0000 Replying to myself. On Tue, 14 Jun 2005, Vladimir Kushnir wrote: > Hi all, > Has anybody had any luck with this combination? So far no matter what I do > stock X (xorg-server) just hangs my box, and xorg-server-snapshot displays > absolutely distorted picture (wrong timings?) with xterm pulled over entire > screen and so forth :-( > Box: -CURRENT (the same was with 5.4 release), Athlon64 (naturally :-), Asus > A8N SLI (not Deluxe), Sapphire Radeon X600 > It appears this is a (bug? feature?) of Xorg: Radeons X600 Series (ID 0x5B62) aren't included in correct CHIP_FAMILY in driver. Workaround: add ChipID 0x5b60 to "Device" section of xorg.conf (passing for X300). More permanent solution: apply this one-liner: *** programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c.orig Thu Jun 23 00:56:51 2005 --- programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c Thu Jun 23 00:57:08 2005 *************** *** 2496,2501 **** --- 2496,2502 ---- case PCI_CHIP_RV370_5460: case PCI_CHIP_RV370_5464: info->IsMobility = TRUE; + case PCI_CHIP_RV370_5B62: case PCI_CHIP_RV370_5B60: case PCI_CHIP_RV370_5B64: case PCI_CHIP_RV370_5B65: Regards, Vladimir From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 22:19:44 2005 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 AC21B16A41C for ; Wed, 22 Jun 2005 22:19:44 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7515A43D1F for ; Wed, 22 Jun 2005 22:19:44 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 01B1151206; Wed, 22 Jun 2005 18:19:42 -0400 (EDT) Date: Wed, 22 Jun 2005 18:19:42 -0400 From: Kris Kennaway To: freebsd-amd64@freebsd.org Message-ID: <20050622221942.GA36733@xor.obsecurity.org> References: <42B409A7.5020909@mail.uni-mainz.de> <42B417C7.80904@samsco.org> <20050619043539.GA46516@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <20050619043539.GA46516@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: 6.0-Current and gcc 4.x 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, 22 Jun 2005 22:19:44 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 18, 2005 at 09:35:39PM -0700, David O'Brien wrote: > On Sat, Jun 18, 2005 at 06:47:03AM -0600, Scott Long wrote: > > Given all the disruptions in the past 3 years over gcc > > 3.x, I think it would be nice to take a small break and not be on the > > bleeding edge of gcc. >=20 > I think you're grossly over exagerating the "disruptions" over GCC 3.x. The ABI breakage at numerous points early in the GCC 3.x branch was extremely disruptive. Kris --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCueP+Wry0BWjoQKURAgy/AKCPyMp1pIcZ2g2QSlyyWn/iDsaTOACfTQvo O2EDmRsARW9SuQvc+EZiAbs= =u1Sn -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 22:25:17 2005 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 8B8EF16A41C for ; Wed, 22 Jun 2005 22:25:17 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ED9843D49 for ; Wed, 22 Jun 2005 22:25:17 +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 19EBBF1C53; Wed, 22 Jun 2005 15:25:17 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55995-07; Wed, 22 Jun 2005 15:25:08 -0700 (PDT) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 8DDB0F1BFA; Wed, 22 Jun 2005 15:25:08 -0700 (PDT) From: Sean McNeil To: Kris Kennaway In-Reply-To: <20050622221942.GA36733@xor.obsecurity.org> References: <42B409A7.5020909@mail.uni-mainz.de> <42B417C7.80904@samsco.org> <20050619043539.GA46516@dragon.NUXI.org> <20050622221942.GA36733@xor.obsecurity.org> Content-Type: text/plain Organization: Sean McNeil Consulting, Inc Date: Wed, 22 Jun 2005 15:25:08 -0700 Message-Id: <1119479108.2709.3.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Cc: freebsd-amd64@freebsd.org Subject: Re: 6.0-Current and gcc 4.x X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sean@mcneil.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2005 22:25:17 -0000 On Wed, 2005-06-22 at 18:19 -0400, Kris Kennaway wrote: > On Sat, Jun 18, 2005 at 09:35:39PM -0700, David O'Brien wrote: > > On Sat, Jun 18, 2005 at 06:47:03AM -0600, Scott Long wrote: > > > Given all the disruptions in the past 3 years over gcc > > > 3.x, I think it would be nice to take a small break and not be on the > > > bleeding edge of gcc. > > > > I think you're grossly over exagerating the "disruptions" over GCC 3.x. > > The ABI breakage at numerous points early in the GCC 3.x branch was > extremely disruptive. This is the amd64 mailing list, so I assume you are talking about amd64 machines and I thought the architecture wasn't really supported before GCC 3.x. In any event, I doubt there would be any such disruption between 3.x and 4.x. The amd64 ABI is pretty solid now, correct? Cheers, Sean From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 22:52:02 2005 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 09EB516A41C for ; Wed, 22 Jun 2005 22:52:02 +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 DECDC43D53 for ; Wed, 22 Jun 2005 22:52:01 +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 j5MMq1cn009350; Wed, 22 Jun 2005 15:52:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j5MMq1rd009349; Wed, 22 Jun 2005 15:52:01 -0700 (PDT) (envelope-from sgk) Date: Wed, 22 Jun 2005 15:52:01 -0700 From: Steve Kargl To: Sean McNeil Message-ID: <20050622225201.GA8836@troutmask.apl.washington.edu> References: <42B409A7.5020909@mail.uni-mainz.de> <42B417C7.80904@samsco.org> <20050619043539.GA46516@dragon.NUXI.org> <20050622221942.GA36733@xor.obsecurity.org> <1119479108.2709.3.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1119479108.2709.3.camel@server.mcneil.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org, Kris Kennaway Subject: Re: 6.0-Current and gcc 4.x 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, 22 Jun 2005 22:52:02 -0000 On Wed, Jun 22, 2005 at 03:25:08PM -0700, Sean McNeil wrote: > On Wed, 2005-06-22 at 18:19 -0400, Kris Kennaway wrote: > > > > The ABI breakage at numerous points early in the GCC 3.x branch was > > extremely disruptive. > > This is the amd64 mailing list, so I assume you are talking about amd64 > machines and I thought the architecture wasn't really supported before > GCC 3.x. In any event, I doubt there would be any such disruption > between 3.x and 4.x. The amd64 ABI is pretty solid now, correct? > The machine description for amd64 may not have changed. The ABI breakage may have occurred at the shared library level. GCC is preparing an early release of 4.0.1 in part to address breakage where KDE does not work correctly and/or can't even be compiled with 4.0.0. -- Steve From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 23:01:34 2005 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 8A52216A41C for ; Wed, 22 Jun 2005 23:01:34 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59FAE43D53 for ; Wed, 22 Jun 2005 23:01:34 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 00D7797084; Wed, 22 Jun 2005 16:01:25 -0700 (PDT) Message-Id: <3.0.1.32.20050622160137.00a87c38@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Wed, 22 Jun 2005 16:01:37 -0700 To: "Steven Hartland" , From: ray@redshift.com In-Reply-To: <0b2601c57753$0a0a8660$7f06000a@int.mediasurface.com> References: <3.0.1.32.20050622104159.00a55450@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Subject: Re: Slower MySQL inserts for AMD64/Opteron? 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, 22 Jun 2005 23:01:34 -0000 I think it's just a little odd that the AMD would be twice as fast with selects yet 20% slower on inserts. As far as variables, both machines are running pretty much the same config. I'm going to install i386 on the AMD and re-run the tests to see if the problem has to do with something in i386 vs. AMD64. Anyway, thanks. Like you say, there are a few variables here - I was really hoping to maybe run across someone that had been down this road before and could comment on maybe something I'm over looking. According to the FAE at AMD, even on a bad day the Dual 246 opteron should drag the Xeon through the mud - but so far nothing here has shown that to be the case. It just feels like I've missed some big thing I'm supposed to do to get the AMD in high gear on FreeBSD - but so far I am at a loss as to what that is. Nothing against AMD, but so far the big solution (or potential solution) which has been suggested was to install i386 so the AMD didn't have to deal with 64 bit pointer (or something along those lines). That's fine and I'm going to test that, but it just makes me wonder why a possible solution would be to install the i386 code vs. the AMD64 code, when that's supposed to be much better right? Anyway, I'm still hunting around, but I thought maybe someone might have some suggestions and/or ideas to test out. Ray At 06:51 PM 6/22/2005 +0100, Steven Hartland wrote: | Too many variables there too draw any conclusions from the comparison. | Compare like for like. | | Steve / K | ----- Original Message ----- | From: | | | >I did some benchmarks recently on a single 2.4Ghz Xeon against a Dual 246 | > Opteron and noticed when it came to MySQL inserts, the single Xeon was about 20% | > faster on inserts (and it actually had a slower hard drive, IDE vs SATA). The | > interesting thing is that the Dual Opterons was twice as fast retrieving the | > data using selects. | > | > Does anyone have any ideas as to why the single Xeon would beat it on inserts? | > I've seen other benchmarks floating around (e.g. Tom's hardware guide) that | > seems to mirror the results I found. I also spoke to AMD about it and they only | > suggestion was to try running i386 on the AMD, as opposed to AMD64. They also | > mentioned something about perhaps compiler switches, but so far I haven't heard | > back, nor have I had a chance to test further. | > | > The Xeon was running 5.3/i386. I believe the AMD was running 5.4/AMD64. | > | > If anyone has any ideas as to what might be the cause, I would be interested in | > hearing. I'm getting ready to load i386 on the AMD (using a spare drive) just | > to see if this makes a difference. Am I over looking something that is required | > to unlock the power of the AMD? The selects being twice as fast was great, but | > then again the AMD has two CPU's also. | | | ================================================ | This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. | | In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 | or return the E.mail to postmaster@multiplay.co.uk. | | | From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 23:05:43 2005 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 BF66816A41C for ; Wed, 22 Jun 2005 23:05:43 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F99343D4C for ; Wed, 22 Jun 2005 23:05:43 +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 6D3B3F1C03; Wed, 22 Jun 2005 16:05:43 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55995-09; Wed, 22 Jun 2005 16:05:35 -0700 (PDT) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id D6C03F19E0; Wed, 22 Jun 2005 16:05:34 -0700 (PDT) From: Sean McNeil To: Steve Kargl In-Reply-To: <20050622225201.GA8836@troutmask.apl.washington.edu> References: <42B409A7.5020909@mail.uni-mainz.de> <42B417C7.80904@samsco.org> <20050619043539.GA46516@dragon.NUXI.org> <20050622221942.GA36733@xor.obsecurity.org> <1119479108.2709.3.camel@server.mcneil.com> <20050622225201.GA8836@troutmask.apl.washington.edu> Content-Type: text/plain Organization: Sean McNeil Consulting, Inc Date: Wed, 22 Jun 2005 16:05:34 -0700 Message-Id: <1119481534.2853.6.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 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: 6.0-Current and gcc 4.x X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sean@mcneil.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2005 23:05:43 -0000 On Wed, 2005-06-22 at 15:52 -0700, Steve Kargl wrote: > On Wed, Jun 22, 2005 at 03:25:08PM -0700, Sean McNeil wrote: > > On Wed, 2005-06-22 at 18:19 -0400, Kris Kennaway wrote: > > > > > > The ABI breakage at numerous points early in the GCC 3.x branch was > > > extremely disruptive. > > > > This is the amd64 mailing list, so I assume you are talking about amd64 > > machines and I thought the architecture wasn't really supported before > > GCC 3.x. In any event, I doubt there would be any such disruption > > between 3.x and 4.x. The amd64 ABI is pretty solid now, correct? > > > > The machine description for amd64 may not have changed. > The ABI breakage may have occurred at the shared library > level. GCC is preparing an early release of 4.0.1 in part > to address breakage where KDE does not work correctly and/or > can't even be compiled with 4.0.0. Interesting. Wonder if it is just a C++ ABI breakage (which happens often) or something more fundamental. I think it has been said before that the FreeBSD folks prefer to wait several "dot" revisions after ".0" before looking into a switch for just these kinds of reasons. Sean From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 23:15:16 2005 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 A01D216A41C for ; Wed, 22 Jun 2005 23:15:16 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F7D743D49 for ; Wed, 22 Jun 2005 23:15:15 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.4/8.13.1) with ESMTP id j5MNFEh5050566; Wed, 22 Jun 2005 16:15:15 -0700 (PDT) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.4/8.13.1/Submit) id j5MNF8a3050565; Wed, 22 Jun 2005 16:15:08 -0700 (PDT) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Vladimir Kushnir In-Reply-To: <20050623011049.R3714@kushnir1.kiev.ua> References: <20050614000247.X30515@kushnir1.kiev.ua> <20050623011049.R3714@kushnir1.kiev.ua> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 22 Jun 2005 16:15:08 -0700 Message-Id: <1119482108.1173.1.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-amd64@freebsd.org Subject: Re: SOLVED: nForce4 + PCIE Radeons - anybody? 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, 22 Jun 2005 23:15:16 -0000 On Thu, 2005-06-23 at 01:16 +0300, Vladimir Kushnir wrote: > Replying to myself. > > On Tue, 14 Jun 2005, Vladimir Kushnir wrote: > > > Hi all, > > Has anybody had any luck with this combination? So far no matter what I do > > stock X (xorg-server) just hangs my box, and xorg-server-snapshot displays > > absolutely distorted picture (wrong timings?) with xterm pulled over entire > > screen and so forth :-( > > Box: -CURRENT (the same was with 5.4 release), Athlon64 (naturally :-), Asus > > A8N SLI (not Deluxe), Sapphire Radeon X600 > > > > It appears this is a (bug? feature?) of Xorg: Radeons X600 Series (ID > 0x5B62) aren't included in correct CHIP_FAMILY in driver. Workaround: add > ChipID 0x5b60 > to "Device" section of xorg.conf (passing for X300). More permanent > solution: apply this one-liner: > > *** programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c.orig Thu Jun 23 00:56:51 2005 > --- programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c Thu Jun 23 00:57:08 2005 > *************** > *** 2496,2501 **** > --- 2496,2502 ---- > case PCI_CHIP_RV370_5460: > case PCI_CHIP_RV370_5464: > info->IsMobility = TRUE; > + case PCI_CHIP_RV370_5B62: > case PCI_CHIP_RV370_5B60: > case PCI_CHIP_RV370_5B64: > case PCI_CHIP_RV370_5B65: I've committed your fix upstream to X.Org and to the xorg-server port. I'm testing xorg-server-snap now. Thanks! -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 23:27:19 2005 Return-Path: X-Original-To: freebsd-amd64@FreeBSD.org Delivered-To: freebsd-amd64@FreeBSD.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 828D516A41C; Wed, 22 Jun 2005 23:27:18 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <42B9F3D6.3040509@freebsd.org> Date: Thu, 23 Jun 2005 07:27:18 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.8) Gecko/20050605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ray@redshift.com References: <3.0.1.32.20050622104159.00a55450@pop.redshift.com> <3.0.1.32.20050622160137.00a87c38@pop.redshift.com> In-Reply-To: <3.0.1.32.20050622160137.00a87c38@pop.redshift.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@FreeBSD.org Subject: Re: Slower MySQL inserts for AMD64/Opteron? 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, 22 Jun 2005 23:27:19 -0000 MySQL's default table type MYISAM is not designed for concurrent insertion from multiple threads, can you test it against InnoDB type ? David Xu ray@redshift.com wrote: >I think it's just a little odd that the AMD would be twice as fast with selects >yet 20% slower on inserts. As far as variables, both machines are running >pretty much the same config. I'm going to install i386 on the AMD and re-run >the tests to see if the problem has to do with something in i386 vs. AMD64. > > From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 22 23:30:53 2005 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 E92D316A41C; Wed, 22 Jun 2005 23:30:53 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id D378843D49; Wed, 22 Jun 2005 23:30:53 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 1F9B397098; Wed, 22 Jun 2005 16:30:52 -0700 (PDT) Message-Id: <3.0.1.32.20050622163104.00a7b0c8@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Wed, 22 Jun 2005 16:31:04 -0700 To: David Xu From: ray@redshift.com In-Reply-To: <42B9F3D6.3040509@freebsd.org> References: <3.0.1.32.20050622160137.00a87c38@pop.redshift.com> <3.0.1.32.20050622104159.00a55450@pop.redshift.com> <3.0.1.32.20050622160137.00a87c38@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-amd64@FreeBSD.org Subject: Re: Slower MySQL inserts for AMD64/Opteron? 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, 22 Jun 2005 23:30:54 -0000 Hi David, Sorry, I forgot to mention my benchmarks were done using InnoDB tables and I configured MySQL on both machines to use InnoDB. BTW, I did not compile in Linux threads on either machine and I don't believe they are there by default. I can send my little benchmark program to anyone that would like to test it on their config. It just has 1 table and a couple of PHP scripts that do inserts, updates, etc. I did compile in APC on my machines, but I don't think that's the bottle neck here, so I doubt if it would impact the results either way. Thanks! Ray At 07:27 AM 6/23/2005 +0800, David Xu wrote: | MySQL's default table type MYISAM is not designed for concurrent insertion | from multiple threads, can you test it against InnoDB type ? | | David Xu | | ray@redshift.com wrote: | | | >I think it's just a little odd that the AMD would be twice as fast with selects | >yet 20% slower on inserts. As far as variables, both machines are running | >pretty much the same config. I'm going to install i386 on the AMD and re-run | >the tests to see if the problem has to do with something in i386 vs. AMD64. | > | > | | | From owner-freebsd-amd64@FreeBSD.ORG Thu Jun 23 01:30:19 2005 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 DD37016A41C for ; Thu, 23 Jun 2005 01:30:19 +0000 (GMT) (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 9FFE443D1F for ; Thu, 23 Jun 2005 01:30:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5N1UJLF052972 for ; Thu, 23 Jun 2005 01:30:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5N1UJoN052965; Thu, 23 Jun 2005 01:30:19 GMT (envelope-from gnats) Resent-Date: Thu, 23 Jun 2005 01:30:19 GMT Resent-Message-Id: <200506230130.j5N1UJoN052965@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, Dmitry Selin Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09DE216A41C for ; Thu, 23 Jun 2005 01:26:12 +0000 (GMT) (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 D142943D48 for ; Thu, 23 Jun 2005 01:26:11 +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 j5N1Q9WQ013171 for ; Thu, 23 Jun 2005 01:26:09 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j5N1Q8uw013170; Thu, 23 Jun 2005 01:26:08 GMT (envelope-from nobody) Message-Id: <200506230126.j5N1Q8uw013170@www.freebsd.org> Date: Thu, 23 Jun 2005 01:26:08 GMT From: Dmitry Selin To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/82555: Kernel Panic - after i connect to my "amd64" from another network bsd box [ssh session]. "nve0" don't work corectly, system hang up, or message and then hang up 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, 23 Jun 2005 01:30:20 -0000 >Number: 82555 >Category: amd64 >Synopsis: Kernel Panic - after i connect to my "amd64" from another network bsd box [ssh session]. "nve0" don't work corectly, system hang up, or message and then hang up >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 23 01:30:18 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Dmitry Selin >Release: 6-CURRENT (Jun 2005) >Organization: Khabarovsk Oil Refinery >Environment: # uname -a FreeBSD prg_1.zup.local 6.0-CURRENT FreeBSD 6.0-CURRENT #1: Mon Jun 20 10:41:32 UTC 2005 selin@prg_test.zup.local:/usr/obj/usr/src/sys/K2K amd64 #dmesg 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-CURRENT #1: Mon Jun 20 10:41:32 UTC 2005 selin@prg_test.zup.local:/usr/obj/usr/src/sys/K2K WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3000+ (1809.28-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x10ff0 Stepping = 0 Features=0x78bfbff AMD Features=0xe2500800,LM,3DNow+,3DNow> real memory = 535691264 (510 MB) avail memory = 508215296 (484 MB) ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR pci_link0: on acpi0 pci_link1: on acpi0 pci_link2: irq 5 on acpi0 pci_link3: on acpi0 pci_link4: on acpi0 pci_link5: irq 11 on acpi0 pci_link6: on acpi0 pci_link7: irq 10 on acpi0 pci_link8: irq 11 on acpi0 pci_link9: on acpi0 pci_link10: irq 10 on acpi0 pci_link11: irq 5 on acpi0 pci_link12: on acpi0 pci_link13: irq 10 on acpi0 pci_link14: irq 11 on acpi0 pci_link15: on acpi0 pci_link16: irq 0 on acpi0 pci_link17: irq 0 on acpi0 pci_link18: irq 0 on acpi0 pci_link19: irq 0 on acpi0 pci_link20: irq 16 on acpi0 pci_link21: irq 0 on acpi0 pci_link22: irq 0 on acpi0 pci_link23: irq 0 on acpi0 pci_link24: irq 0 on acpi0 pci_link25: irq 0 on acpi0 pci_link26: irq 0 on acpi0 pci_link27: irq 0 on acpi0 pci_link28: irq 0 on acpi0 pci_link29: irq 0 on acpi0 pci_link30: irq 0 on acpi0 pci_link31: irq 0 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci_link26: Unable to choose an IRQ pci_link21: Unable to choose an IRQ pci_link27: Unable to choose an IRQ pci_link24: Unable to choose an IRQ pci_link29: Unable to choose an IRQ pci_link30: Unable to choose an IRQ pci_link23: Unable to choose an IRQ pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfebff000-0xfebfffff irq 21 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xfebfe000-0xfebfe0ff irq 22 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 10 ports with 10 removable, self powered pci0: at device 4.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 6.0 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xcc00-0xcc0f mem 0xfebfb000-0xfebfbfff irq 21 at device 7.0 on pci0 ata2: on atapci1 ata3: on atapci1 atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xb800-0xb80f mem 0xfebfa000-0xfebfafff irq 22 at device 8.0 on pci0 ata4: on atapci2 ata5: on atapci2 pcib1: at device 9.0 on pci0 pci_link17: BIOS IRQ 21 for 0.7.INTA is invalid pci_link18: BIOS IRQ 22 for 0.8.INTA is invalid pci_link16: BIOS IRQ 23 for 0.10.INTA is invalid pci1: on pcib1 nve0: port 0xb400-0xb407 mem 0xfebf9000-0xfebf9fff irq 23 at device 10.0 on pci0 nve0: Ethernet address 00:11:5b:c5:e4:89 miibus0: on nve0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nve0: Ethernet address: 00:11:5b:c5:e4:89 nve0: [GIANT-LOCKED] pcib2: at device 11.0 on pci0 pci2: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 pcib4: at device 13.0 on pci0 pci4: on pcib4 pcib5: at device 14.0 on pci0 pci5: on pcib5 pci_link18: Unable to choose an IRQ pci5: at device 0.0 (no driver attached) pci5: at device 0.1 (no driver attached) acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 ppi0: on ppbus0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 orm0: at iomem 0xc0000-0xccfff,0xd0000-0xd17ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1809281099 Hz quality 800 Timecounters tick every 1.000 msec ad0: 114473MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s2a WARNING: was not properly dismounted WARNING: was not properly dismounted WARNING: was not properly dismounted WARNING: was not properly dismounted WARNING: was not properly dismounted #sysctl -a kern.ostype: FreeBSD kern.osrelease: 6.0-CURRENT kern.osrevision: 199506 kern.version: FreeBSD 6.0-CURRENT #1: Mon Jun 20 10:41:32 UTC 2005 selin@prg_test.zup.local:/usr/obj/usr/src/sys/K2K kern.maxvnodes: 35287 kern.maxproc: 4036 kern.maxfiles: 8072 kern.argmax: 262144 kern.securelevel: -1 kern.hostname: prg_1.zup.local kern.hostid: 0 kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 } kern.posix1version: 200112 kern.ngroups: 16 kern.job_control: 1 kern.saved_ids: 0 kern.boottime: { sec = 1119525436, usec = 806216 } Thu Jun 23 11:17:16 2005 kern.domainname: kern.osreldate: 600031 kern.bootfile: /boot/kernel/kernel kern.maxfilesperproc: 7264 kern.maxprocperuid: 3632 kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 60 kern.ipc.max_hdr: 76 kern.ipc.max_datalen: 100 kern.ipc.nmbclusters: 17088 kern.ipc.piperesizeallowed: 1 kern.ipc.piperesizefail: 0 kern.ipc.pipeallocfail: 0 kern.ipc.pipefragretry: 0 kern.ipc.pipekva: 36864 kern.ipc.pipes: 4 kern.ipc.maxpipekva: 8531968 kern.ipc.msgseg: 2048 kern.ipc.msgssz: 8 kern.ipc.msgtql: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgmni: 40 kern.ipc.msgmax: 16384 kern.ipc.semaem: 16384 kern.ipc.semvmx: 32767 kern.ipc.semusz: 104 kern.ipc.semume: 10 kern.ipc.semopm: 100 kern.ipc.semmsl: 60 kern.ipc.semmnu: 30 kern.ipc.semmns: 60 kern.ipc.semmni: 10 kern.ipc.semmap: 30 kern.ipc.shm_allow_removed: 0 kern.ipc.shm_use_phys: 0 kern.ipc.shmall: 8192 kern.ipc.shmseg: 128 kern.ipc.shmmni: 192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 33554432 kern.ipc.numopensockets: 13 kern.ipc.maxsockets: 8072 kern.ipc.nsfbufsused: 0 kern.ipc.nsfbufspeak: 0 kern.ipc.nsfbufs: 0 kern.dummy: 0 kern.ps_strings: 140737488355296 kern.usrstack: 140737488355328 kern.logsigexit: 1 kern.iov_max: 1024 kern.disks: ad0 kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.elf64.fallback_brand: -1 kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall kern.acct_chkfreq: 15 kern.acct_resume: 4 kern.acct_suspend: 2 kern.cp_time: 82 1 413 152 32419 kern.openfiles: 62 kern.kq_calloutmax: 4096 kern.ps_arg_cache_limit: 256 kern.stackprot: 7 kern.randompid: 0 kern.lastpid: 539 kern.ktrace.request_pool: 100 kern.ktrace.genio_size: 4096 kern.module_path: /boot/kernel;/boot/modules kern.malloc: Type InUse MemUse HighUse Requests Size(s) linux 10 1K - 10 64 isadev 5 1K - 5 128 atkbddev 2 1K - 2 64 GEOM 102 23K - 544 16,32,64,128,256,512,1024,2048,4096 nexusdev 2 1K - 2 16 acpidev 93 6K - 93 64 I/O APIC 1 2K - 1 2048 memdesc 1 4K - 1 4096 pfs_nodes 49 7K - 49 128 VM pgdata 2 65K - 2 128 UMAHash 1 1K - 2 512,1024 UFS mount 15 33K - 15 512,2048,4096 UFS dirhash 48 9K - 48 16,32,64,512 pagedep 2 33K - 15 128 inodedep 2 257K - 50 256 newblk 1 1K - 31 64,512 bmsafemap 0 0K - 11 64 allocdirect 0 0K - 30 128 freefrag 0 0K - 2 64 freeblks 0 0K - 18 256 freefile 0 0K - 21 64 diradd 1 1K - 33 64 mkdir 0 0K - 12 64 dirrem 0 0K - 26 64 savedino 0 0K - 21 256 p1003.1b 1 1K - 1 16 in6_multi 7 1K - 7 64 syncache 1 12K - 1 hostcache 1 48K - 1 in_multi 2 1K - 2 64 routetbl 30 4K - 87 32,64,128,256,512 NTFS nthash 1 256K - 1 MSDOSFS mount 2 1K - 2 256,512 lo 1 1K - 1 32 arpcom 1 1K - 1 32 clone 4 16K - 4 4096 ifnet 4 7K - 4 512,2048 ifaddr 28 11K - 29 32,64,256,512,4096 ether_multi 30 2K - 30 16,32,64 BPF 7 9K - 7 128,512,4096 MSDOSFS FAT 1 332K - 1 mount 141 13K - 237 16,32,64,128,256,512,1024,2048 vnodes 1 1K - 1 256 VFS hash 1 256K - 1 vfscache 1 512K - 1 BIO buffer 82 164K - 86 2048 MSDOSFS node 16 4K - 16 256 soname 3 1K - 179 16,32,128 pcb 10 9K - 26 16,32,64,128,4096 mbuf tags 0 0K - 9 32 ttys 1051 149K - 4321 128,1024 shm 1 16K - 1 sem 4 8K - 4 1024,2048,4096 msg 4 30K - 4 2048,4096 ioctlops 0 0K - 1655 16,32,64,256,512,1024,2048,4096 iov 0 0K - 255 64,128,256 DEVFS 108 33K - 109 16,64,128,256 USB 32 5K - 32 16,32,64,128,256,512 USBdev 3 2K - 9 16,512 Unitno 6 1K - 6 64 turnstiles 103 13K - 103 128 taskqueue 6 2K - 6 256 entropy 1024 64K - 1024 64 ppbusdev 3 1K - 3 256 sleep queues 103 7K - 103 64 sbuf 0 0K - 402 16,32,64,128,256,512,1024,2048,4096 acpipwr 2 1K - 2 64 rman 198 25K - 532 16,128 acpica 2923 300K - 36559 16,32,64,128,256,512,1024,2048 kobj 110 440K - 126 4096 eventhandler 35 4K - 35 64,256 devstat 10 21K - 10 32,4096 bus 744 66K - 4423 16,32,64,128,256,512,1024 bus-sc 89 37K - 1599 16,32,64,128,256,512,1024,2048,4096 SWAP 2 141K - 2 64 umtx 102 13K - 102 128 sysctl 0 0K - 83 16,32,64 sysctloid 3369 164K - 3369 16,32,64,128 sysctltmp 0 0K - 271 16,32,64,128 plimit 14 4K - 154 256 uidinfo 5 2K - 12 64,1024 cred 18 5K - 1353 256 pgrp 22 3K - 25 128 session 20 5K - 21 256 proc 2 8K - 2 4096 subproc 169 358K - 631 512,4096 mtx_pool 1 12K - 1 module 176 22K - 176 128 devbuf 1454 4186K - 1456 16,32,64,128,256,512,1024,2048,4096 temp 14 31K - 4033 16,32,64,128,256,512,1024,2048,4096 ip6ndp 5 1K - 6 64,128,256 lockf 3 1K - 5 128 linker 35 3K - 45 16,32,64,512 acpi_perf 1 1K - 1 128 KTRACE 100 13K - 100 128 acpisem 17 3K - 17 128 PCI Link 64 6K - 64 16,64,128 ithread 52 11K - 54 128,256 acpitask 0 0K - 3 64 zombie 0 0K - 462 256 proc-args 24 2K - 312 16,32,64,128,256 kqueue 0 0K - 26 256,2048 kenv 53 6K - 54 16,32,64,4096 file desc 78 39K - 540 512 sigio 1 1K - 1 64 ACD driver 1 2K - 1 2048 cdev 85 43K - 85 512 ATA DMA 6 2K - 6 256 AD driver 1 1K - 1 32 ATA generic 2 2K - 2 1024 kern.fallback_elf_brand: -1 kern.maxusers: 251 kern.ident: K2K kern.kstack_pages: 4 kern.shutdown.kproc_shutdown_wait: 60 kern.shutdown.poweroff_delay: 5000 kern.sync_on_panic: 0 kern.corefile: %N.core kern.nodump_coredump: 0 kern.coredump: 1 kern.sugid_coredump: 0 kern.fscale: 2048 kern.timecounter.tick: 1 kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast kern.timecounter.nsetclock: 2 kern.timecounter.ngetmicrotime: 122942 kern.timecounter.ngetnanotime: 513 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetmicrouptime: 14677 kern.timecounter.ngetnanouptime: 31 kern.timecounter.ngetbinuptime: 585 kern.timecounter.nmicrotime: 2779 kern.timecounter.nnanotime: 7 kern.timecounter.nbintime: 2786 kern.timecounter.nmicrouptime: 587 kern.timecounter.nnanouptime: 0 kern.timecounter.nbinuptime: 171969 kern.timecounter.stepwarnings: 0 kern.threads.thr_concurrency: 0 kern.threads.thr_scope: 0 kern.threads.virtual_cpu: 1 kern.threads.max_threads_hits: 0 kern.threads.max_groups_per_proc: 1500 kern.threads.max_threads_per_proc: 1500 kern.threads.debug: 0 kern.ccpu: 1948 kern.sched.preemption: 1 kern.sched.kgfollowons: 0 kern.sched.pfollowons: 0 kern.sched.followon: 0 kern.sched.quantum: 100000 kern.sched.name: 4BSD kern.devstat.version: 6 kern.devstat.generation: 141 kern.devstat.numdevs: 1 kern.kobj_methodcount: 93 kern.log_wakeups_per_second: 5 kern.msgbuf_clear: 0 kern.msgbuf: kern.always_console_output: 0 kern.log_console_output: 1 kern.smp.cpus: 1 kern.smp.disabled: 0 kern.smp.active: 0 kern.smp.maxcpus: 1 kern.nselcoll: 0 kern.tty_nout: 616160 kern.tty_nin: 987 kern.drainwait: 300 kern.constty_wakeups_per_second: 5 kern.consmsgbuf_size: 8192 kern.consmute: 0 kern.console: consolectl,/ttyd0,consolectl, kern.minvnodes: 8821 kern.metadelay: 28 kern.dirdelay: 29 kern.filedelay: 30 kern.chroot_allow_open_directories: 1 kern.elf32.fallback_brand: -1 kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 192 kern.random.yarrow.slowthresh: 256 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0 vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 22) Virtual Memory: (Total: 26912K, Active 25800K) Real Memory: (Total: 46912K Active 15768K) Shared Virtual Memory: (Total: 8228K Active: 7716K) Shared Real Memory: (Total: 6536K Active: 6292K) Free Memory Pages: 447848K vm.loadavg: { 0,01 0,02 0,00 } vm.v_free_min: 867 vm.v_free_target: 3712 vm.v_free_reserved: 244 vm.v_inactive_target: 5568 vm.v_cache_min: 3712 vm.v_cache_max: 7424 vm.v_pageout_free_min: 34 vm.pageout_algorithm: 0 vm.swap_enabled: 1 vm.kmem_size_scale: 3 vm.kmem_size_max: 419430400 vm.kmem_size: 170672128 vm.nswapdev: 1 vm.dmmax: 32 vm.swap_async_max: 4 vm.zone: ITEM SIZE LIMIT USED FREE REQUESTS FFS2 dinode: 256, 0, 547, 8, 514 FFS1 dinode: 128, 0, 0, 0, 0 FFS inode: 192, 0, 547, 33, 525 SWAPMETA: 288, 62504, 0, 0, 0 rtentry: 264, 0, 14, 14, 0 ripcb: 304, 8076, 0, 0, 0 sackhole: 32, 0, 0, 0, 0 tcpreass: 40, 1092, 0, 0, 0 hostcache: 136, 15372, 0, 0, 0 syncache: 128, 15370, 0, 0, 0 tcptw: 80, 1620, 0, 0, 0 tcpcb: 744, 8075, 3, 7, 0 inpcb: 304, 8076, 3, 21, 0 udpcb: 304, 8076, 2, 22, 0 unpcb: 192, 17100, 7, 33, 0 socket: 568, 8078, 13, 8, 49 KNOTE: 120, 0, 0, 62, 0 PIPE: 720, 0, 2, 13, 123 DIRHASH: 1024, 0, 50, 6, 37 L VFS Cache: 327, 0, 0, 0, 0 S VFS Cache: 104, 0, 582, 30, 1135 NAMEI: 1024, 0, 0, 20, 3671 VNODEPOLL: 128, 0, 0, 0, 0 VNODE: 496, 0, 610, 30, 623 ata_composit: 368, 0, 0, 0, 0 ata_request: 328, 0, 0, 60, 3632 g_bio: 216, 0, 0, 252, 12388 MbufClust: 2048, 17088, 128, 6, 117 Mbuf: 256, 0, 129, 141, 0 Packet: 256, 0, 192, 78, 0 VMSPACE: 544, 0, 24, 18, 417 UPCALL: 88, 0, 0, 0, 0 KSEGRP: 136, 0, 90, 40, 74 THREAD: 600, 0, 90, 12, 76 PROC: 808, 0, 77, 13, 462 Files: 120, 0, 62, 62, 1688 4096: 4096, 0, 259, 20, 3080 2048: 2048, 0, 98, 4, 182 1024: 1024, 0, 57, 135, 666 512: 512, 0, 317, 19, 1046 256: 256, 0, 456, 39, 2343 128: 128, 0, 4745, 69, 11784 64: 64, 0, 3406, 122, 4746 32: 32, 0, 1495, 222, 1933 16: 16, 0, 1732, 116, 32332 mt_zone: 64, 0, 163, 61, 115 DP fakepg: 120, 0, 0, 0, 0 PV ENTRY: 48, 938016, 8972, 4060, 272307 MAP ENTRY: 112, 0, 583, 242, 16938 KMAP ENTRY: 112, 31779, 12, 120, 2 MAP: 352, 0, 7, 15, 0 VM OBJECT: 224, 0, 904, 116, 8629 128 Bucket: 1048, 0, 21, 0, 0 64 Bucket: 536, 0, 15, 6, 0 32 Bucket: 280, 0, 28, 0, 0 16 Bucket: 152, 0, 36, 14, 0 UMA Hash: 256, 0, 3, 12, 0 UMA RCntSlab: 128, 0, 67, 20, 0 UMA Slabs: 128, 0, 448, 16, 0 UMA Zones: 152, 0, 59, 13, 0 UMA Kegs: 232, 0, 59, 1, 0 vm.old_contigmalloc: 0 vm.swap_idle_threshold2: 10 vm.swap_idle_threshold1: 2 vm.exec_map_entries: 16 vm.stats.misc.zero_page_count: 80734 vm.stats.misc.cnt_prezero: 97738 vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 0 vm.stats.vm.v_vforkpages: 3037 vm.stats.vm.v_forkpages: 43404 vm.stats.vm.v_kthreads: 54 vm.stats.vm.v_rforks: 0 vm.stats.vm.v_vforks: 30 vm.stats.vm.v_forks: 455 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_cache_max: 7424 vm.stats.vm.v_cache_min: 3712 vm.stats.vm.v_cache_count: 188 vm.stats.vm.v_inactive_count: 2010 vm.stats.vm.v_inactive_target: 5568 vm.stats.vm.v_active_count: 2247 vm.stats.vm.v_wire_count: 7522 vm.stats.vm.v_free_count: 111774 vm.stats.vm.v_free_min: 867 vm.stats.vm.v_free_target: 3712 vm.stats.vm.v_free_reserved: 244 vm.stats.vm.v_page_count: 125006 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_tfree: 39313 vm.stats.vm.v_pfree: 24842 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_pdpages: 0 vm.stats.vm.v_pdwakeups: 0 vm.stats.vm.v_reactivated: 177 vm.stats.vm.v_intrans: 14 vm.stats.vm.v_vnodepgsout: 0 vm.stats.vm.v_vnodepgsin: 2446 vm.stats.vm.v_vnodeout: 0 vm.stats.vm.v_vnodein: 336 vm.stats.vm.v_swappgsout: 0 vm.stats.vm.v_swappgsin: 0 vm.stats.vm.v_swapout: 0 vm.stats.vm.v_swapin: 0 vm.stats.vm.v_ozfod: 16370 vm.stats.vm.v_zfod: 16415 vm.stats.vm.v_cow_optim: 36 vm.stats.vm.v_cow_faults: 16855 vm.stats.vm.v_vm_faults: 45253 vm.stats.sys.v_soft: 3162 vm.stats.sys.v_intr: 54918 vm.stats.sys.v_syscall: 131336 vm.stats.sys.v_trap: 45047 vm.stats.sys.v_swtch: 141272 vm.v_free_severe: 555 vm.max_proc_mmap: 15238 vm.old_msync: 0 vm.msync_flush_flags: 3 vm.pageout_lock_miss: 0 vm.disable_swapspace_pageouts: 0 vm.defer_swapspace_pageouts: 0 vm.swap_idle_enabled: 0 vm.pageout_stats_interval: 5 vm.pageout_full_stats_interval: 20 vm.pageout_stats_max: 3712 vm.max_launder: 32 vm.idlezero_maxrun: 16 vm.idlezero_enable: 1 vm.kvm_free: 1644163072 0 vm.kvm_size: 2147479552 0 vfs.devfs.topinode: 88 vfs.devfs.inodes: 85 vfs.devfs.generation: 85 vfs.devfs.noverflow: 32768 vfs.ufs.dirhash_docheck: 0 vfs.ufs.dirhash_mem: 58514 vfs.ufs.dirhash_maxmem: 2097152 vfs.ufs.dirhash_minsize: 2560 vfs.pfs.vncache.misses: 0 vfs.pfs.vncache.hits: 0 vfs.pfs.vncache.maxentries: 0 vfs.pfs.vncache.entries: 0 vfs.flushwithdeps: 0 vfs.getnewbufrestarts: 0 vfs.getnewbufcalls: 3386 vfs.hifreebuffers: 440 vfs.lofreebuffers: 220 vfs.numfreebuffers: 3860 vfs.dirtybufthresh: 891 vfs.hidirtybuffers: 991 vfs.lodirtybuffers: 495 vfs.numdirtybuffers: 26 vfs.recursiveflushes: 0 vfs.altbufferflushes: 0 vfs.dirtybufferflushes: 0 vfs.hirunningspace: 1048576 vfs.lorunningspace: 524288 vfs.bufdefragcnt: 0 vfs.buffreekvacnt: 7 vfs.bufreusecnt: 3353 vfs.hibufspace: 63012864 vfs.lobufspace: 62947328 vfs.maxmallocbufspace: 3150643 vfs.bufmallocspace: 167936 vfs.maxbufspace: 63668224 vfs.bufspace: 55066624 vfs.runningbufspace: 0 vfs.vmiodirenable: 1 vfs.cache.numfullpathfound: 66 vfs.cache.numfullpathfail4: 0 vfs.cache.numfullpathfail2: 0 vfs.cache.numfullpathfail1: 0 vfs.cache.numfullpathcalls: 66 vfs.cache.nchstats: 14474 1032 36 0 1418 0 20 124 vfs.cache.numneghits: 1032 vfs.cache.numnegzaps: 11 vfs.cache.numposhits: 14474 vfs.cache.numposzaps: 25 vfs.cache.nummisszap: 19 vfs.cache.nummiss: 1399 vfs.cache.numchecks: 15547 vfs.cache.dotdothits: 13 vfs.cache.dothits: 51 vfs.cache.numcalls: 17024 vfs.cache.numcache: 582 vfs.cache.numneg: 36 vfs.read_max: 8 vfs.write_behind: 1 vfs.lookup_shared: 0 vfs.usermount: 0 vfs.worklist_len: 7 vfs.timestamp_precision: 0 vfs.reassignbufcalls: 686 vfs.freevnodes: 59 vfs.wantfreevnodes: 8821 vfs.numvnodes: 610 vfs.ffs.doreallocblks: 1 vfs.ffs.doasyncfree: 1 vfs.ffs.compute_summary_at_mount: 0 net.local.stream.recvspace: 8192 net.local.stream.sendspace: 8192 net.local.dgram.recvspace: 4096 net.local.dgram.maxdgram: 2048 net.local.inflight: 0 net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.forwarding: 0 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.subnets_are_local: 0 net.inet.ip.fastforwarding: 0 net.inet.ip.check_interface: 0 net.inet.ip.random_id: 0 net.inet.ip.sendsourcequench: 0 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.maxfragpackets: 534 net.inet.ip.process_options: 1 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.bmcastecho: 0 net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 0 net.inet.icmp.maskfake: 0 net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 0 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.reass.overflows: 0 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 1068 net.inet.tcp.insecure_rst: 0 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 3 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.minmssoverload: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15359 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies: 1 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 3 net.inet.tcp.msl: 30000 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.strict_mcast_mship: 0 net.inet.udp.blackhole: 0 net.inet.udp.log_in_vain: 0 net.inet.raw.recvspace: 8192 net.inet.raw.maxdgram: 8192 net.inet.accf.unloadable: 0 net.link.generic.system.ifcount: 3 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.proxyall: 0 net.link.ether.inet.useloopback: 1 net.link.ether.inet.maxtries: 5 net.link.ether.inet.host_down_time: 20 net.link.ether.inet.max_age: 1200 net.link.ether.inet.prune_intvl: 300 net.link.ether.ipfw: 0 net.link.gif.parallel_tunnels: 0 net.link.gif.max_nesting: 1 net.link.log_link_state_change: 1 net.inet6.ip6.forwarding: 0 net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 net.inet6.ip6.maxfragpackets: 4272 net.inet6.ip6.accept_rtadv: 0 net.inet6.ip6.keepfaith: 0 net.inet6.ip6.log_interval: 5 net.inet6.ip6.hdrnestlimit: 50 net.inet6.ip6.dad_count: 1 net.inet6.ip6.auto_flowlabel: 1 net.inet6.ip6.defmcasthlim: 1 net.inet6.ip6.gifhlim: 30 net.inet6.ip6.kame_version: 20010528/FreeBSD net.inet6.ip6.use_deprecated: 1 net.inet6.ip6.rr_prune: 5 net.inet6.ip6.v6only: 1 net.inet6.ip6.rtexpire: 3600 net.inet6.ip6.rtminexpire: 10 net.inet6.ip6.rtmaxcache: 128 net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.temppltime: 86400 net.inet6.ip6.tempvltime: 604800 net.inet6.ip6.auto_linklocal: 1 net.inet6.ip6.prefer_tempaddr: 0 net.inet6.ip6.maxfrags: 4272 net.inet6.icmp6.rediraccept: 1 net.inet6.icmp6.redirtimeout: 600 net.inet6.icmp6.nd6_prune: 1 net.inet6.icmp6.nd6_delay: 5 net.inet6.icmp6.nd6_umaxtries: 3 net.inet6.icmp6.nd6_mmaxtries: 3 net.inet6.icmp6.nd6_useloopback: 1 net.inet6.icmp6.nodeinfo: 3 net.inet6.icmp6.errppslimit: 100 net.inet6.icmp6.nd6_maxnudhint: 0 net.inet6.icmp6.nd6_debug: 0 net.bpf.maxinsns: 512 net.bpf.maxbufsize: 524288 net.bpf.bufsize: 4096 net.isr.swi_count: 354 net.isr.drop: 0 net.isr.queued: 10 net.isr.deferred: 344 net.isr.directed: 0 net.isr.count: 344 net.isr.enable: 0 net.route.netisr_maxqlen: 256 debug.ddb_use_printf: 0 debug.acpi.semaphore_debug: 0 debug.acpi.do_powerstate: 1 debug.acpi.acpi_ca_version: 0x20041119 debug.firewire_debug: 0 debug.fwmem_debug: 0 debug.mddebug: 0 debug.elf64_legacy_coredump: 0 debug.elf64_trace: 0 debug.bootverbose: 0 debug.boothowto: 0 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 debug.sizeof.g_bioq: 96 debug.sizeof.g_consumer: 96 debug.sizeof.g_provider: 136 debug.sizeof.g_geom: 136 debug.sizeof.g_class: 136 debug.sizeof.kinfo_proc: 1088 debug.sizeof.buf: 584 debug.sizeof.bio: 216 debug.sizeof.cdev: 288 debug.sizeof.proc: 808 debug.sizeof.vnode: 496 debug.sizeof.devstat: 288 debug.trace_on_panic: 0 debug.debugger_on_panic: 1 debug.to_avg_mpcalls: 999 debug.to_avg_mtxcalls: 0 debug.to_avg_gcalls: 232 debug.to_avg_depth: 1253 debug.kdb.enter: 0 debug.kdb.current: ddb debug.kdb.available: ddb debug.rman_debug: 0 debug.witness.skipspin: 1 debug.witness.trace: 1 debug.witness.kdb: 0 debug.witness.watch: 1 debug.ttydebug: 0 debug.disablefullpath: 0 debug.disablecwd: 0 debug.hashstat.nchash: 65536 579 2 88 debug.ncsize: 72 debug.vnsize: 496 debug.vfscache: 1 debug.numcachehv: 87 debug.numcache: 582 debug.numneg: 36 debug.ncnegfactor: 16 debug.nchash: 65535 debug.vnlru_nowhere: 0 debug.rush_requests: 0 debug.mpsafevfs: 1 debug.if_tun_debug: 0 debug.mpsafenet: 1 debug.collectsnapstats: 0 debug.snapdebug: 0 debug.dopersistence: 0 debug.worklist_num: 0 debug.dir_entry: 6 debug.direct_blk_ptrs: 1 debug.inode_bitmap: 11 debug.indir_blk_ptrs: 0 debug.sync_limit_hit: 0 debug.ino_limit_hit: 0 debug.blk_limit_hit: 0 debug.ino_limit_push: 0 debug.blk_limit_push: 0 debug.worklist_push: 0 debug.maxindirdeps: 50 debug.tickdelay: 2 debug.max_softdeps: 141148 debug.dobkgrdwrite: 1 debug.bigcgs: 0 debug.dircheck: 0 debug.nosleepwithlocks: 1 debug.mpsafevm: 1 debug.psm.pkterrthresh: 2 debug.psm.usecs: 500000 debug.psm.secs: 0 debug.psm.errusecs: 0 debug.psm.errsecs: 2 debug.psm.hz: 20 debug.psm.loglevel: 0 debug.fdc.settle: 125 debug.fdc.spec2: 16 debug.fdc.spec1: 175 debug.fdc.retries: 10 debug.fdc.debugflags: 0 debug.fdc.fifo: 8 debug.elf32_legacy_coredump: 0 debug.elf32_trace: 0 hw.machine: amd64 hw.model: AMD Athlon(tm) 64 Processor 3000+ hw.ncpu: 1 hw.byteorder: 1234 hw.physmem: 527982592 hw.usermem: 497172480 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: amd64 hw.realmem: 535691264 hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.ata.ata_dma: 1 hw.firewire.hold_count: 3 hw.firewire.try_bmr: 1 hw.firewire.fwmem.speed: 2 hw.firewire.fwmem.eui64_lo: 0 hw.firewire.fwmem.eui64_hi: 0 hw.pci.do_powerstate: 1 hw.pci.enable_io_modes: 1 hw.pci.host_mem_start: 2147483648 hw.intr_storm_threshold: 500 hw.availpages: 128902 hw.bus.devctl_disable: 0 hw.busdma.total_bpages: 545 hw.busdma.zone0.total_bpages: 512 hw.busdma.zone0.free_bpages: 512 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 256 hw.busdma.zone0.boundary: 0 hw.busdma.zone1.total_bpages: 1 hw.busdma.zone1.free_bpages: 1 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.active_bpages: 0 hw.busdma.zone1.total_bounced: 0 hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.lowaddr: 0xffffffff hw.busdma.zone1.alignment: 4096 hw.busdma.zone1.boundary: 0 hw.busdma.zone2.total_bpages: 32 hw.busdma.zone2.free_bpages: 32 hw.busdma.zone2.reserved_bpages: 0 hw.busdma.zone2.active_bpages: 0 hw.busdma.zone2.total_bounced: 0 hw.busdma.zone2.total_deferred: 0 hw.busdma.zone2.lowaddr: 0xffffffff hw.busdma.zone2.alignment: 2 hw.busdma.zone2.boundary: 65536 hw.clockrate: 1809 hw.instruction_sse: 1 hw.psm.tap_timeout: 125000 hw.psm.tap_threshold: 25 hw.kbd.keymap_restrict_change: 0 hw.nve_pollinterval: 0 hw.syscons.bell: 1 hw.syscons.saver.keybonly: 1 hw.syscons.sc_no_suspend_vtswitch: 0 hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.tz0.temperature: 40.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 122.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 124.0C hw.acpi.thermal.tz0._ACx: 122.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 machdep.adjkerntz: 0 machdep.disable_rtc_set: 0 machdep.wall_cmos_clock: 0 machdep.acpi_timer_freq: 3579545 machdep.acpi_root: 1013104 machdep.disable_mtrrs: 0 machdep.cpu_idle_hlt: 1 machdep.panic_on_nmi: 1 machdep.kdb_on_nmi: 1 machdep.tsc_freq: 1809281091 machdep.i8254_freq: 1193182 machdep.conspeed: 9600 machdep.gdbspeed: 9600 machdep.conrclk: 1843200 machdep.enable_panic_key: 0 user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: user.bc_base_max: 99 user.bc_dim_max: 2048 user.bc_scale_max: 99 user.bc_string_max: 1000 user.coll_weights_max: 0 user.expr_nest_max: 32 user.line_max: 2048 user.re_dup_max: 255 user.posix2_version: 199212 user.posix2_c_bind: 0 user.posix2_c_dev: 0 user.posix2_char_term: 0 user.posix2_fort_dev: 0 user.posix2_fort_run: 0 user.posix2_localedef: 0 user.posix2_sw_dev: 0 user.posix2_upe: 0 user.stream_max: 20 user.tzname_max: 255 p1003_1b.asynchronous_io: 0 p1003_1b.mapped_files: 1 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 0 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 1 p1003_1b.realtime_signals: 0 p1003_1b.semaphores: 0 p1003_1b.fsync: 0 p1003_1b.shared_memory_objects: 1 p1003_1b.synchronized_io: 0 p1003_1b.timers: 0 p1003_1b.aio_listio_max: -1 p1003_1b.aio_max: -1 p1003_1b.aio_prio_delta_max: -1 p1003_1b.delaytimer_max: 0 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 0 p1003_1b.sem_nsems_max: 0 p1003_1b.sem_value_max: 0 p1003_1b.sigqueue_max: 0 p1003_1b.timer_max: 0 security.jail.jailed: 0 security.jail.chflags_allowed: 0 security.jail.allow_raw_sockets: 0 security.jail.enforce_statfs: 2 security.jail.sysvipc_allowed: 0 security.jail.socket_unixiproute_only: 1 security.jail.set_hostname_allowed: 1 security.bsd.unprivileged_proc_debug: 1 security.bsd.conservative_signals: 1 security.bsd.see_other_gids: 1 security.bsd.see_other_uids: 1 security.bsd.suser_enabled: 1 security.bsd.unprivileged_read_msgbuf: 1 security.bsd.hardlink_check_gid: 0 security.bsd.hardlink_check_uid: 0 security.bsd.unprivileged_get_quota: 0 compat.ia32.maxvmem: 0 compat.ia32.maxssiz: 67108864 compat.ia32.maxdsiz: 536870912 compat.linux32.maxvmem: 0 compat.linux32.maxssiz: 67108864 compat.linux32.maxdsiz: 536870912 compat.linux.oss_version: 198144 compat.linux.osrelease: 2.4.2 compat.linux.osname: Linux dev.nexus.0.%driver: nexus dev.nexus.0.%parent: root0 dev.acpi.0.%desc: Nvidia AWRDACPI dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.MBIO dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C02 _UID=5 dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_sysresource.1.%desc: System Resource dev.acpi_sysresource.1.%driver: acpi_sysresource dev.acpi_sysresource.1.%location: handle=\_SB_.PCI0.SYSR dev.acpi_sysresource.1.%pnpinfo: _HID=PNP0C02 _UID=1 dev.acpi_sysresource.1.%parent: acpi0 dev.acpi_sysresource.2.%desc: System Resource dev.acpi_sysresource.2.%driver: acpi_sysresource dev.acpi_sysresource.2.%location: handle=\_SB_.PCI0.EXPL dev.acpi_sysresource.2.%pnpinfo: _HID=PNP0C02 _UID=4 dev.acpi_sysresource.2.%parent: acpi0 dev.acpi_sysresource.3.%desc: System Resource dev.acpi_sysresource.3.%driver: acpi_sysresource dev.acpi_sysresource.3.%location: handle=\_SB_.MEM_ dev.acpi_sysresource.3.%pnpinfo: _HID=PNP0C01 _UID=0 dev.acpi_sysresource.3.%parent: acpi0 dev.pci_link.0.%desc: ACPI PCI Link LNK1 dev.pci_link.0.%driver: pci_link dev.pci_link.0.%location: handle=\_SB_.PCI0.LNK1 dev.pci_link.0.%pnpinfo: _HID=PNP0C0F _UID=1 dev.pci_link.0.%parent: acpi0 dev.pci_link.1.%desc: ACPI PCI Link LNK2 dev.pci_link.1.%driver: pci_link dev.pci_link.1.%location: handle=\_SB_.PCI0.LNK2 dev.pci_link.1.%pnpinfo: _HID=PNP0C0F _UID=2 dev.pci_link.1.%parent: acpi0 dev.pci_link.2.%desc: ACPI PCI Link LNK3 dev.pci_link.2.%driver: pci_link dev.pci_link.2.%location: handle=\_SB_.PCI0.LNK3 dev.pci_link.2.%pnpinfo: _HID=PNP0C0F _UID=3 dev.pci_link.2.%parent: acpi0 dev.pci_link.3.%desc: ACPI PCI Link LNK4 dev.pci_link.3.%driver: pci_link dev.pci_link.3.%location: handle=\_SB_.PCI0.LNK4 dev.pci_link.3.%pnpinfo: _HID=PNP0C0F _UID=4 dev.pci_link.3.%parent: acpi0 dev.pci_link.4.%desc: ACPI PCI Link LNK5 dev.pci_link.4.%driver: pci_link dev.pci_link.4.%location: handle=\_SB_.PCI0.LNK5 dev.pci_link.4.%pnpinfo: _HID=PNP0C0F _UID=5 dev.pci_link.4.%parent: acpi0 dev.pci_link.5.%desc: ACPI PCI Link LUBA dev.pci_link.5.%driver: pci_link dev.pci_link.5.%location: handle=\_SB_.PCI0.LUBA dev.pci_link.5.%pnpinfo: _HID=PNP0C0F _UID=6 dev.pci_link.5.%parent: acpi0 dev.pci_link.6.%desc: ACPI PCI Link LUBB dev.pci_link.6.%driver: pci_link dev.pci_link.6.%location: handle=\_SB_.PCI0.LUBB dev.pci_link.6.%pnpinfo: _HID=PNP0C0F _UID=7 dev.pci_link.6.%parent: acpi0 dev.pci_link.7.%desc: ACPI PCI Link LMAC dev.pci_link.7.%driver: pci_link dev.pci_link.7.%location: handle=\_SB_.PCI0.LMAC dev.pci_link.7.%pnpinfo: _HID=PNP0C0F _UID=8 dev.pci_link.7.%parent: acpi0 dev.pci_link.8.%desc: ACPI PCI Link LACI dev.pci_link.8.%driver: pci_link dev.pci_link.8.%location: handle=\_SB_.PCI0.LACI dev.pci_link.8.%pnpinfo: _HID=PNP0C0F _UID=10 dev.pci_link.8.%parent: acpi0 dev.pci_link.9.%desc: ACPI PCI Link LMCI dev.pci_link.9.%driver: pci_link dev.pci_link.9.%location: handle=\_SB_.PCI0.LMCI dev.pci_link.9.%pnpinfo: _HID=PNP0C0F _UID=11 dev.pci_link.9.%parent: acpi0 dev.pci_link.10.%desc: ACPI PCI Link LSMB dev.pci_link.10.%driver: pci_link dev.pci_link.10.%location: handle=\_SB_.PCI0.LSMB dev.pci_link.10.%pnpinfo: _HID=PNP0C0F _UID=12 dev.pci_link.10.%parent: acpi0 dev.pci_link.11.%desc: ACPI PCI Link LUB2 dev.pci_link.11.%driver: pci_link dev.pci_link.11.%location: handle=\_SB_.PCI0.LUB2 dev.pci_link.11.%pnpinfo: _HID=PNP0C0F _UID=13 dev.pci_link.11.%parent: acpi0 dev.pci_link.12.%desc: ACPI PCI Link LIDE dev.pci_link.12.%driver: pci_link dev.pci_link.12.%location: handle=\_SB_.PCI0.LIDE dev.pci_link.12.%pnpinfo: _HID=PNP0C0F _UID=16 dev.pci_link.12.%parent: acpi0 dev.pci_link.13.%desc: ACPI PCI Link LSID dev.pci_link.13.%driver: pci_link dev.pci_link.13.%location: handle=\_SB_.PCI0.LSID dev.pci_link.13.%pnpinfo: _HID=PNP0C0F _UID=17 dev.pci_link.13.%parent: acpi0 dev.pci_link.14.%desc: ACPI PCI Link LFID dev.pci_link.14.%driver: pci_link dev.pci_link.14.%location: handle=\_SB_.PCI0.LFID dev.pci_link.14.%pnpinfo: _HID=PNP0C0F _UID=18 dev.pci_link.14.%parent: acpi0 dev.pci_link.15.%desc: ACPI PCI Link LPCA dev.pci_link.15.%driver: pci_link dev.pci_link.15.%location: handle=\_SB_.PCI0.LPCA dev.pci_link.15.%pnpinfo: _HID=PNP0C0F _UID=19 dev.pci_link.15.%parent: acpi0 dev.pci_link.16.%desc: ACPI PCI Link APC1 dev.pci_link.16.%driver: pci_link dev.pci_link.16.%location: handle=\_SB_.PCI0.APC1 dev.pci_link.16.%pnpinfo: _HID=PNP0C0F _UID=20 dev.pci_link.16.%parent: acpi0 dev.pci_link.17.%desc: ACPI PCI Link APC2 dev.pci_link.17.%driver: pci_link dev.pci_link.17.%location: handle=\_SB_.PCI0.APC2 dev.pci_link.17.%pnpinfo: _HID=PNP0C0F _UID=21 dev.pci_link.17.%parent: acpi0 dev.pci_link.18.%desc: ACPI PCI Link APC3 dev.pci_link.18.%driver: pci_link dev.pci_link.18.%location: handle=\_SB_.PCI0.APC3 dev.pci_link.18.%pnpinfo: _HID=PNP0C0F _UID=22 dev.pci_link.18.%parent: acpi0 dev.pci_link.19.%desc: ACPI PCI Link APC4 dev.pci_link.19.%driver: pci_link dev.pci_link.19.%location: handle=\_SB_.PCI0.APC4 dev.pci_link.19.%pnpinfo: _HID=PNP0C0F _UID=23 dev.pci_link.19.%parent: acpi0 dev.pci_link.20.%desc: ACPI PCI Link APC5 dev.pci_link.20.%driver: pci_link dev.pci_link.20.%location: handle=\_SB_.PCI0.APC5 dev.pci_link.20.%pnpinfo: _HID=PNP0C0F _UID=24 dev.pci_link.20.%parent: acpi0 dev.pci_link.21.%desc: ACPI PCI Link APCF dev.pci_link.21.%driver: pci_link dev.pci_link.21.%location: handle=\_SB_.PCI0.APCF dev.pci_link.21.%pnpinfo: _HID=PNP0C0F _UID=25 dev.pci_link.21.%parent: acpi0 dev.pci_link.22.%desc: ACPI PCI Link APCG dev.pci_link.22.%driver: pci_link dev.pci_link.22.%location: handle=\_SB_.PCI0.APCG dev.pci_link.22.%pnpinfo: _HID=PNP0C0F _UID=26 dev.pci_link.22.%parent: acpi0 dev.pci_link.23.%desc: ACPI PCI Link APCH dev.pci_link.23.%driver: pci_link dev.pci_link.23.%location: handle=\_SB_.PCI0.APCH dev.pci_link.23.%pnpinfo: _HID=PNP0C0F _UID=27 dev.pci_link.23.%parent: acpi0 dev.pci_link.24.%desc: ACPI PCI Link APCJ dev.pci_link.24.%driver: pci_link dev.pci_link.24.%location: handle=\_SB_.PCI0.APCJ dev.pci_link.24.%pnpinfo: _HID=PNP0C0F _UID=29 dev.pci_link.24.%parent: acpi0 dev.pci_link.25.%desc: ACPI PCI Link APCK dev.pci_link.25.%driver: pci_link dev.pci_link.25.%location: handle=\_SB_.PCI0.APCK dev.pci_link.25.%pnpinfo: _HID=PNP0C0F _UID=30 dev.pci_link.25.%parent: acpi0 dev.pci_link.26.%desc: ACPI PCI Link APCS dev.pci_link.26.%driver: pci_link dev.pci_link.26.%location: handle=\_SB_.PCI0.APCS dev.pci_link.26.%pnpinfo: _HID=PNP0C0F _UID=31 dev.pci_link.26.%parent: acpi0 dev.pci_link.27.%desc: ACPI PCI Link APCL dev.pci_link.27.%driver: pci_link dev.pci_link.27.%location: handle=\_SB_.PCI0.APCL dev.pci_link.27.%pnpinfo: _HID=PNP0C0F _UID=32 dev.pci_link.27.%parent: acpi0 dev.pci_link.28.%desc: ACPI PCI Link APCZ dev.pci_link.28.%driver: pci_link dev.pci_link.28.%location: handle=\_SB_.PCI0.APCZ dev.pci_link.28.%pnpinfo: _HID=PNP0C0F _UID=35 dev.pci_link.28.%parent: acpi0 dev.pci_link.29.%desc: ACPI PCI Link APSI dev.pci_link.29.%driver: pci_link dev.pci_link.29.%location: handle=\_SB_.PCI0.APSI dev.pci_link.29.%pnpinfo: _HID=PNP0C0F _UID=36 dev.pci_link.29.%parent: acpi0 dev.pci_link.30.%desc: ACPI PCI Link APSJ dev.pci_link.30.%driver: pci_link dev.pci_link.30.%location: handle=\_SB_.PCI0.APSJ dev.pci_link.30.%pnpinfo: _HID=PNP0C0F _UID=37 dev.pci_link.30.%parent: acpi0 dev.pci_link.31.%desc: ACPI PCI Link APCP dev.pci_link.31.%driver: pci_link dev.pci_link.31.%location: handle=\_SB_.PCI0.APCP dev.pci_link.31.%pnpinfo: _HID=PNP0C0F _UID=38 dev.pci_link.31.%parent: acpi0 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1810 dev.cpu.0.freq_levels: 1810/-1 1583/-1 1357/-1 1131/-1 905/-1 678/-1 452/-1 226/-1 dev.acpi_perf.0.%driver: acpi_perf dev.acpi_perf.0.%parent: cpu0 dev.acpi_throttle.0.%desc: ACPI CPU Throttling dev.acpi_throttle.0.%driver: acpi_throttle dev.acpi_throttle.0.%parent: cpu0 dev.acpi_throttle.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.acpi_button.0.%desc: Power Button dev.acpi_button.0.%driver: acpi_button dev.acpi_button.0.%location: handle=\_SB_.PWRB dev.acpi_button.0.%pnpinfo: _HID=PNP0C0C _UID=0 dev.acpi_button.0.%parent: acpi0 dev.pcib.0.%desc: ACPI Host-PCI bridge dev.pcib.0.%driver: pcib dev.pcib.0.%location: handle=\_SB_.PCI0 dev.pcib.0.%pnpinfo: _HID=PNP0A08 _UID=1 dev.pcib.0.%parent: acpi0 dev.pcib.1.%desc: ACPI PCI-PCI bridge dev.pcib.1.%driver: pcib dev.pcib.1.%location: slot=9 function=0 handle=\_SB_.PCI0.HUB0 dev.pcib.1.%pnpinfo: vendor=0x10de device=0x005c subvendor=0x0000 subdevice=0x0000 class=0x060401 dev.pcib.1.%parent: pci0 dev.pcib.1.wake: 0 dev.pcib.2.%desc: ACPI PCI-PCI bridge dev.pcib.2.%driver: pcib dev.pcib.2.%location: slot=11 function=0 handle=\_SB_.PCI0.XVR3 dev.pcib.2.%pnpinfo: vendor=0x10de device=0x005d subvendor=0x0040 subdevice=0x0000 class=0x060400 dev.pcib.2.%parent: pci0 dev.pcib.2.wake: 0 dev.pcib.3.%desc: ACPI PCI-PCI bridge dev.pcib.3.%driver: pcib dev.pcib.3.%location: slot=12 function=0 handle=\_SB_.PCI0.XVR2 dev.pcib.3.%pnpinfo: vendor=0x10de device=0x005d subvendor=0x0040 subdevice=0x0000 class=0x060400 dev.pcib.3.%parent: pci0 dev.pcib.3.wake: 0 dev.pcib.4.%desc: ACPI PCI-PCI bridge dev.pcib.4.%driver: pcib dev.pcib.4.%location: slot=13 function=0 handle=\_SB_.PCI0.XVR1 dev.pcib.4.%pnpinfo: vendor=0x10de device=0x005d subvendor=0x0040 subdevice=0x0000 class=0x060400 dev.pcib.4.%parent: pci0 dev.pcib.4.wake: 0 dev.pcib.5.%desc: ACPI PCI-PCI bridge dev.pcib.5.%driver: pcib dev.pcib.5.%location: slot=14 function=0 handle=\_SB_.PCI0.XVR0 dev.pcib.5.%pnpinfo: vendor=0x10de device=0x005d subvendor=0x0040 subdevice=0x0000 class=0x060400 dev.pcib.5.%parent: pci0 dev.pcib.5.wake: 0 dev.pci.0.%desc: ACPI PCI bus dev.pci.0.%driver: pci dev.pci.0.%parent: pcib0 dev.pci.1.%desc: ACPI PCI bus dev.pci.1.%driver: pci dev.pci.1.%parent: pcib1 dev.pci.1.wake: 0 dev.pci.2.%desc: ACPI PCI bus dev.pci.2.%driver: pci dev.pci.2.%parent: pcib2 dev.pci.2.wake: 0 dev.pci.3.%desc: ACPI PCI bus dev.pci.3.%driver: pci dev.pci.3.%parent: pcib3 dev.pci.3.wake: 0 dev.pci.4.%desc: ACPI PCI bus dev.pci.4.%driver: pci dev.pci.4.%parent: pcib4 dev.pci.4.wake: 0 dev.pci.5.%desc: ACPI PCI bus dev.pci.5.%driver: pci dev.pci.5.%parent: pcib5 dev.pci.5.wake: 0 dev.isab.0.%desc: PCI-ISA bridge dev.isab.0.%driver: isab dev.isab.0.%location: slot=1 function=0 handle=\_SB_.PCI0.VT86 dev.isab.0.%pnpinfo: vendor=0x10de device=0x0050 subvendor=0x1019 subdevice=0x1b51 class=0x060100 dev.isab.0.%parent: pci0 dev.isa.0.%desc: ISA bus dev.isa.0.%driver: isa dev.isa.0.%parent: isab0 dev.ohci.0.%desc: OHCI (generic) USB controller dev.ohci.0.%driver: ohci dev.ohci.0.%location: slot=2 function=0 handle=\_SB_.PCI0.USB0 dev.ohci.0.%pnpinfo: vendor=0x10de device=0x005a subvendor=0x1019 subdevice=0x1b51 class=0x0c0310 dev.ohci.0.%parent: pci0 dev.ohci.0.wake: 0 dev.usb.0.%desc: OHCI (generic) USB controller dev.usb.0.%driver: usb dev.usb.0.%parent: ohci0 dev.usb.1.%desc: EHCI (generic) USB 2.0 controller dev.usb.1.%driver: usb dev.usb.1.%parent: ehci0 dev.uhub.0.%desc: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.0.%driver: uhub dev.uhub.0.%parent: usb0 dev.uhub.1.%desc: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 dev.uhub.1.%driver: uhub dev.uhub.1.%parent: usb1 dev.ehci.0.%desc: EHCI (generic) USB 2.0 controller dev.ehci.0.%driver: ehci dev.ehci.0.%location: slot=2 function=1 handle=\_SB_.PCI0.USB2 dev.ehci.0.%pnpinfo: vendor=0x10de device=0x005b subvendor=0x1019 subdevice=0x1b51 class=0x0c0320 dev.ehci.0.%parent: pci0 dev.ehci.0.wake: 0 dev.atapci.0.%desc: nVidia nForce4 UDMA133 controller dev.atapci.0.%driver: atapci dev.atapci.0.%location: slot=6 function=0 handle=\_SB_.PCI0.IDE0 dev.atapci.0.%pnpinfo: vendor=0x10de device=0x0053 subvendor=0x1019 subdevice=0x1b51 class=0x01018a dev.atapci.0.%parent: pci0 dev.atapci.1.%desc: nVidia nForce4 SATA150 controller dev.atapci.1.%driver: atapci dev.atapci.1.%location: slot=7 function=0 handle=\_SB_.PCI0.SAT1 dev.atapci.1.%pnpinfo: vendor=0x10de device=0x0054 subvendor=0x1019 subdevice=0x1b51 class=0x010185 dev.atapci.1.%parent: pci0 dev.atapci.2.%desc: nVidia nForce4 SATA150 controller dev.atapci.2.%driver: atapci dev.atapci.2.%location: slot=8 function=0 handle=\_SB_.PCI0.SAT2 dev.atapci.2.%pnpinfo: vendor=0x10de device=0x0055 subvendor=0x10de subdevice=0xcb84 class=0x010185 dev.atapci.2.%parent: pci0 dev.ata.0.%desc: ATA channel 0 dev.ata.0.%driver: ata dev.ata.0.%parent: atapci0 dev.ata.1.%desc: ATA channel 1 dev.ata.1.%driver: ata dev.ata.1.%parent: atapci0 dev.ata.2.%desc: ATA channel 0 dev.ata.2.%driver: ata dev.ata.2.%parent: atapci1 dev.ata.3.%desc: ATA channel 1 dev.ata.3.%driver: ata dev.ata.3.%parent: atapci1 dev.ata.4.%desc: ATA channel 0 dev.ata.4.%driver: ata dev.ata.4.%parent: atapci2 dev.ata.5.%desc: ATA channel 1 dev.ata.5.%driver: ata dev.ata.5.%parent: atapci2 dev.nve.0.%desc: NVIDIA nForce MCP9 Networking Adapter dev.nve.0.%driver: nve dev.nve.0.%location: slot=10 function=0 handle=\_SB_.PCI0.MMAC dev.nve.0.%pnpinfo: vendor=0x10de device=0x0057 subvendor=0x1019 subdevice=0x1b51 class=0x068000 dev.nve.0.%parent: pci0 dev.nve.0.wake: 0 dev.miibus.0.%desc: MII bus dev.miibus.0.%driver: miibus dev.miibus.0.%parent: nve0 dev.ukphy.0.%desc: Generic IEEE 802.3u media interface dev.ukphy.0.%driver: ukphy dev.ukphy.0.%location: phyno=1 dev.ukphy.0.%pnpinfo: oui=0x5043 model=0xc rev=0x2 dev.ukphy.0.%parent: miibus0 dev.hostb.0.%desc: Host to PCI bridge dev.hostb.0.%driver: hostb dev.hostb.0.%location: slot=24 function=0 handle=\_SB_.PCI0.K800 dev.hostb.0.%pnpinfo: vendor=0x1022 device=0x1100 subvendor=0x0000 subdevice=0x0000 class=0x060000 dev.hostb.0.%parent: pci0 dev.hostb.1.%desc: Host to PCI bridge dev.hostb.1.%driver: hostb dev.hostb.1.%location: slot=24 function=1 handle=\_SB_.PCI0.K801 dev.hostb.1.%pnpinfo: vendor=0x1022 device=0x1101 subvendor=0x0000 subdevice=0x0000 class=0x060000 dev.hostb.1.%parent: pci0 dev.hostb.2.%desc: Host to PCI bridge dev.hostb.2.%driver: hostb dev.hostb.2.%location: slot=24 function=2 handle=\_SB_.PCI0.K802 dev.hostb.2.%pnpinfo: vendor=0x1022 device=0x1102 subvendor=0x0000 subdevice=0x0000 class=0x060000 dev.hostb.2.%parent: pci0 dev.hostb.3.%desc: Host to PCI bridge dev.hostb.3.%driver: hostb dev.hostb.3.%location: slot=24 function=3 dev.hostb.3.%pnpinfo: vendor=0x1022 device=0x1103 subvendor=0x0000 subdevice=0x0000 class=0x060000 dev.hostb.3.%parent: pci0 dev.acpi_tz.0.%desc: Thermal Zone dev.acpi_tz.0.%driver: acpi_tz dev.acpi_tz.0.%location: handle=\_TZ_.THRM dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 dev.acpi_tz.0.%parent: acpi0 dev.atpic.0.%desc: AT interrupt controller dev.atpic.0.%driver: atpic dev.atpic.0.%location: handle=\_SB_.PCI0.PIC_ dev.atpic.0.%pnpinfo: _HID=PNP0000 _UID=0 dev.atpic.0.%parent: acpi0 dev.atdma.0.%desc: AT DMA controller dev.atdma.0.%driver: atdma dev.atdma.0.%location: handle=\_SB_.PCI0.DMA1 dev.atdma.0.%pnpinfo: _HID=PNP0200 _UID=0 dev.atdma.0.%parent: acpi0 dev.attimer.0.%desc: AT timer dev.attimer.0.%driver: attimer dev.attimer.0.%location: handle=\_SB_.PCI0.TMR_ dev.attimer.0.%pnpinfo: _HID=PNP0100 _UID=0 dev.attimer.0.%parent: acpi0 dev.attimer.1.%desc: AT realtime clock dev.attimer.1.%driver: attimer dev.attimer.1.%location: handle=\_SB_.PCI0.RTC_ dev.attimer.1.%pnpinfo: _HID=PNP0B00 _UID=0 dev.attimer.1.%parent: acpi0 dev.fpupnp.0.%desc: Legacy ISA coprocessor support dev.fpupnp.0.%driver: fpupnp dev.fpupnp.0.%location: handle=\_SB_.PCI0.COPR dev.fpupnp.0.%pnpinfo: _HID=PNP0C04 _UID=0 dev.fpupnp.0.%parent: acpi0 dev.fdc.0.%desc: Enhanced floppy controller dev.fdc.0.%driver: fdc dev.fdc.0.%location: handle=\_SB_.PCI0.FDC0 dev.fdc.0.%pnpinfo: _HID=PNP0700 _UID=0 dev.fdc.0.%parent: acpi0 dev.fd.0.%desc: 1440-KB 3.5" drive dev.fd.0.%driver: fd dev.fd.0.%parent: fdc0 dev.sio.0.%desc: 16550A-compatible COM port dev.sio.0.%driver: sio dev.sio.0.%location: handle=\_SB_.PCI0.UAR1 dev.sio.0.%pnpinfo: _HID=PNP0501 _UID=1 dev.sio.0.%parent: acpi0 dev.sio.0.wake: 0 dev.sio.1.%desc: Generic IRDA-compatible device dev.sio.1.%driver: sio dev.sio.1.%location: handle=\_SB_.PCI0.IRDA dev.sio.1.%pnpinfo: _HID=PNP0510 _UID=0 dev.sio.1.%parent: acpi0 dev.ppc.0.%desc: ECP parallel printer port dev.ppc.0.%driver: ppc dev.ppc.0.%location: handle=\_SB_.PCI0.ECP1 dev.ppc.0.%pnpinfo: _HID=PNP0401 _UID=1 dev.ppc.0.%parent: acpi0 dev.ppbus.0.%desc: Parallel port bus dev.ppbus.0.%driver: ppbus dev.ppbus.0.%parent: ppc0 dev.ppi.0.%desc: Parallel I/O dev.ppi.0.%driver: ppi dev.ppi.0.%parent: ppbus0 dev.plip.0.%desc: PLIP network interface dev.plip.0.%driver: plip dev.plip.0.%parent: ppbus0 dev.lpt.0.%desc: Printer dev.lpt.0.%driver: lpt dev.lpt.0.%parent: ppbus0 dev.psmcpnp.0.%desc: PS/2 mouse port dev.psmcpnp.0.%driver: psmcpnp dev.psmcpnp.0.%location: handle=\_SB_.PCI0.PS2M dev.psmcpnp.0.%pnpinfo: _HID=PNP0F13 _UID=0 dev.psmcpnp.0.%parent: acpi0 dev.atkbdc.0.%desc: Keyboard controller (i8042) dev.atkbdc.0.%driver: atkbdc dev.atkbdc.0.%location: handle=\_SB_.PCI0.PS2K dev.atkbdc.0.%pnpinfo: _HID=PNP0303 _UID=0 dev.atkbdc.0.%parent: acpi0 dev.atkbd.0.%desc: AT Keyboard dev.atkbd.0.%driver: atkbd dev.atkbd.0.%parent: atkbdc0 dev.psm.0.%desc: PS/2 Mouse dev.psm.0.%driver: psm dev.psm.0.%parent: atkbdc0 dev.orm.0.%desc: ISA Option ROMs dev.orm.0.%driver: orm dev.orm.0.%parent: isa0 dev.sc.0.%desc: System console dev.sc.0.%driver: sc dev.sc.0.%parent: isa0 dev.vga.0.%desc: Generic ISA VGA dev.vga.0.%driver: vga dev.vga.0.%parent: isa0 dev.ad.0.%desc: ST3120022A/8.54 dev.ad.0.%driver: ad dev.ad.0.%parent: ata0 dev.acd.0.%desc: NEC DVD RW ND-3520A/1.04 dev.acd.0.%driver: acd dev.acd.0.%parent: ata1 #K2K - my kernel config machine amd64 cpu HAMMER ident K2K # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols #options SCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device ##options NFSCLIENT # Network Filesystem Client ##options NFSSERVER # Network Filesystem Server ##options NFS_ROOT # NFS usable as /, requires NFSCLIENT options NTFS # NT File System options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Needed by COMPAT_LINUX32 options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_LINUX32 # Compatible with i386 linux binaries ##options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # Make an SMP-capable kernel by default ##options SMP # Symmetric MultiProcessor Kernel # Workarounds for some known-to-be-broken chipsets (nVidia nForce3-Pro150) device atpic # 8259A compatability # Linux 32-bit ABI support options LINPROCFS # Cannot be a module yet. # Bus support. Do not remove isa, even if you have no isa slots device acpi device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives ##device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives ##device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers ##device ahc # AHA2940 and onboard AIC7xxx devices ##device ahd # AHA39320/29320 and onboard AIC79xx devices ##device amd # AMD 53C974 (Tekram DC-390(T)) ##device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module ##device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic ##device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') ##device trm # Tekram DC395U/UW/F DC315U adapters ##device adv # Advansys SCSI adapters ##device adw # Advansys wide SCSI adapters ##device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. ##device bt # Buslogic/Mylex MultiMaster SCSI adapters # SCSI peripherals ##device scbus # SCSI bus (required for SCSI) ##device ch # SCSI media changers ##device da # Direct Access (disks) ##device sa # Sequential Access (tape etc) ##device cd # CD ##device pass # Passthrough device (direct SCSI access) ##device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem ##device amr # AMI MegaRAID ##device arcmsr # Areca SATA II RAID ##device ciss # Compaq Smart RAID 5* ##device dpt # DPT Smartcache III, IV - See NOTES for options ##device iir # Intel Integrated RAID ##device ips # IBM (Adaptec) ServeRAID ##device mly # Mylex AcceleRAID/eXtremeRAID ##device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers ##device aac # Adaptec FSA RAID ##device aacp # SCSI passthrough for aac (requires CAM) ##device ida # Compaq Smart RAID ##device mlx # Mylex DAC960 family #XXX pointer/int warnings #device pst # Promise Supertrak SX6000 ##device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support ##device cbb # cardbus (yenta) bridge ##device pccard # PC Card (16-bit) bus ##device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support ##device bfe # Broadcom BCM440x 10/100 Ethernet ##device bge # Broadcom BCM570xx Gigabit Ethernet ##device dc # DEC/Intel 21143 and various workalikes ##device fxp # Intel EtherExpress PRO/100B (82557, 82558) ##device lge # Level 1 LXT1001 gigabit Ethernet ##device nge # NatSemi DP83820 gigabit Ethernet device nve # nVidia nForce MCP on-board Ethernet Networking ##device pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') ##device re # RealTek 8139C+/8169/8169S/8110S ##device rl # RealTek 8129/8139 ##device sf # Adaptec AIC-6915 (``Starfire'') ##device sis # Silicon Integrated Systems SiS 900/SiS 7016 ##device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet ##device ste # Sundance ST201 (D-Link DFE-550TX) ##device ti # Alteon Networks Tigon I/II gigabit Ethernet ##device tl # Texas Instruments ThunderLAN ##device tx # SMC EtherPower II (83c170 ``EPIC'') ##device vge # VIA VT612x gigabit Ethernet ##device vr # VIA Rhine, Rhine II ##device wb # Winbond W89C840F ##device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. ##device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' # XXX kvtop brokenness, pointer/int warnings #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards ##device ex # Intel EtherExpress Pro/10 and Pro/10+ ##device ep # Etherlink III based cards ##device fe # Fujitsu MB8696x based cards # XXX kvtop brokenness, pointer/int warnings #device lnc # NE2100, NE32-VL Lance Ethernet cards ##device sn # SMC's 9000 series of Ethernet chips ##device xe # Xircom pccard Ethernet # Wireless NIC cards ##device wlan # 802.11 support ##device an # Aironet 4500/4800 802.11 wireless NICs. ##device awi # BayStack 660 and others ##device ral # Ralink Technology RT2500 wireless NICs. ##device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer ##device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse ##device ural # Ralink Technology RT2500USB wireless NICs ##device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires miibus ##device aue # ADMtek USB Ethernet ##device axe # ASIX Electronics USB Ethernet ##device cdce # Generic USB over Ethernet ##device cue # CATC USB Ethernet ##device kue # Kawasaki LSI USB Ethernet ##device rue # RealTek RTL8150 USB Ethernet # FireWire support device firewire # FireWire bus code ##device sbp # SCSI over FireWire (Requires scbus and da) ##device fwe # Ethernet over FireWire (non-standard!) >Description: prg_1[192.168.2.248]- Amd64-3000(939), 512(2x256dual) - 6.0-CURRENT prg_bsd[192.168.2.249]- Pen266, (32dimm) - 6.0-CURRENT 1)ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/Jun_2005/6.0-CURRENT-SNAP004-amd64-disc1.iso min install 2) sysinstall - network (ssh, ftp, nve0 dhcp) 3) download fresh ncvs, cvsup, cvs co ports, src 4) make buildworld, make kernel... etc 5) cd /usr/ports/mc, make install clean 6) ssh selin@192.168.2.248 - i connect from prg_bsd to prg_1 7) 1-3 min work in terminal and conection with amd64 close - amd64 hangup or message " panic: nve_ifstart: attempted use of a free mbuf! KDB: enter: panic [thread pid 501 tid 100082] Stopped at kdb_enter+0x2f:nop " My Mb: http://www.ecs.com.tw/ECSWeb/Products/ProductsDetail.aspx?DetailID=493&MenuID=90&LanID=0 >How-To-Repeat: prg_1[192.168.2.248]- Amd64-3000(939), 512(2x256dual) - 6.0-CURRENT prg_bsd[192.168.2.249]- Pen266, (32dimm) - 6.0-CURRENT 1)ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/Jun_2005/6.0-CURRENT-SNAP004-amd64-disc1.iso min install 2) sysinstall - network (ssh, ftp, nve0 dhcp) 3) download fresh ncvs, cvsup, cvs co ports, src 4) make buildworld, make kernel... etc 5) cd /usr/ports/mc, make install clean 6) ssh selin@192.168.2.248 - i connect from prg_bsd to prg_1 7) 1-3 min work in terminal and conection with amd64 close - amd64 hangup or message " panic: nve_ifstart: attempted use of a free mbuf! KDB: enter: panic [thread pid 501 tid 100082] Stopped at kdb_enter+0x2f:nop " >Fix: May be not use network adapter on my mb... (but on Win XP 20 day uptime - no problem in LAN) >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Thu Jun 23 08:07:32 2005 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 F065016A420 for ; Thu, 23 Jun 2005 08:07:32 +0000 (GMT) (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 D03A643D58 for ; Thu, 23 Jun 2005 08:07: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 9ECBA2A8F9 for ; Thu, 23 Jun 2005 01:07:32 -0700 (PDT) (envelope-from peter@wemm.org) Received: from peter-laptop.wemm.org (dhcp49.wemm.org [10.0.0.49]) by fw.wemm.org (Postfix) with ESMTP id 3FB25E2B3 for ; Thu, 23 Jun 2005 01:07:32 -0700 (PDT) (envelope-from peter@wemm.org) Received: from peter-laptop.wemm.org (localhost [127.0.0.1]) by peter-laptop.wemm.org (8.13.3/8.13.3) with ESMTP id j5N875AK014192; Thu, 23 Jun 2005 01:07:05 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by peter-laptop.wemm.org (8.13.3/8.13.3/Submit) id j5N870Fx014191; Thu, 23 Jun 2005 01:07:00 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: peter-laptop.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Thu, 23 Jun 2005 01:07:00 -0700 User-Agent: KMail/1.8 References: <42B85A70.3070108@palisadesys.com> In-Reply-To: <42B85A70.3070108@palisadesys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506230107.00574.peter@wemm.org> Cc: Subject: Re: mmap(2) length argument limits 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, 23 Jun 2005 08:07:33 -0000 On Tuesday 21 June 2005 11:20 am, Guy Helmer wrote: > Is mmap(2) truly limited to mapping 2GB chunks of a file, even on 64-bit > platforms where a 64-bit offset in the VM system shouldn't be such a > performance penalty, or does the BUGS section of the mmap(2) man page > apply to 32-bit platforms only? It is a man-page bug on all platforms. You can mmap 3GB on 32 bit systems if you have enough process vm space. eg: if you've shrunk the kva space. -Peter From owner-freebsd-amd64@FreeBSD.ORG Thu Jun 23 13:02:04 2005 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 AEF2B16A41C for ; Thu, 23 Jun 2005 13:02:04 +0000 (GMT) (envelope-from morten@atreides.freenix.no) Received: from freenix.no (atreides.freenix.no [212.33.142.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFE7E43D48 for ; Thu, 23 Jun 2005 13:01:53 +0000 (GMT) (envelope-from morten@atreides.freenix.no) Received: from atreides.freenix.no (localhost [127.0.0.1]) by freenix.no (8.13.1/8.13.1) with ESMTP id j5ND0G4Z078500 for ; Thu, 23 Jun 2005 15:01:01 +0200 (CEST) (envelope-from morten@atreides.freenix.no) Received: (from morten@localhost) by atreides.freenix.no (8.13.1/8.13.1/Submit) id j5ND0A2n078499 for freebsd-amd64@freebsd.org; Thu, 23 Jun 2005 15:00:10 +0200 (CEST) (envelope-from morten) Date: Thu, 23 Jun 2005 15:00:10 +0200 From: "Morten A. Middelthon" To: freebsd-amd64@freebsd.org Message-ID: <20050623130010.GA74413@freenix.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://freenix.no/~morten/pgp.txt X-PGP-Key-FingerPrint: D48B 5C4E 1590 7DE6 08A0 6539 BECC F62E 829F DF6A X-Operating-System: FreeBSD 4.11-RELEASE-p2 X-Warning: So cunning you could brush your teeth with it. X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on atreides.freenix.no X-Virus-Status: Clean Subject: mtx 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, 23 Jun 2005 13:02:04 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, does anyone know the status of mtx on amd64? It's still marked as broken on ia64, sparc64 and amd64. I installed the i386-version via the precompiled package, but it doesn't seem to be working properly, although that might be related to other issues.=20 with regards, --=20 Morten A. Middelthon "First learn computer science and all the theory. Next develop a programmin= g style. Then forget all that and just hack."=20 -- George Carrette --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCurJavsz2LoKf32oRAj1HAJ9icySwYEXKwi8enz6/+k+pyFOfuwCfWasE z4UGafOwbMTP8IdjRDx+cSM= =pPdr -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-amd64@FreeBSD.ORG Thu Jun 23 13:43:20 2005 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 C4D3016A41C for ; Thu, 23 Jun 2005 13:43:20 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id A39BA43D4C for ; Thu, 23 Jun 2005 13:43:20 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5NDhJ54044114; Thu, 23 Jun 2005 06:43:20 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5NDhJNl044113; Thu, 23 Jun 2005 06:43:19 -0700 (PDT) (envelope-from obrien) Date: Thu, 23 Jun 2005 06:43:19 -0700 From: "David O'Brien" To: ray@redshift.com Message-ID: <20050623134319.GA43842@dragon.NUXI.org> References: <3.0.1.32.20050622104159.00a55450@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.1.32.20050622104159.00a55450@pop.redshift.com> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@FreeBSD.org Subject: Re: Slower MySQL inserts for AMD64/Opteron? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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: Thu, 23 Jun 2005 13:43:20 -0000 On Wed, Jun 22, 2005 at 10:41:59AM -0700, ray@redshift.com wrote: > I did some benchmarks recently on a single 2.4Ghz Xeon against a Dual > 246 Opteron and noticed when it came to MySQL inserts, the single Xeon > was about 20% faster on inserts (and it actually had a slower hard > drive, IDE vs SATA). The interesting thing is that the Dual Opterons > was twice as fast retrieving the data using selects. .. > The Xeon was running 5.3/i386. I believe the AMD was running 5.4/AMD64. Note that in 5.4, the ATA subsystem runs without the Big-GIANT-Lock. CAM (SCSI subsystem) still grabs GIANT. For a system with a single activity going on (such as yours), I feel ATA can "out perform" SCSI doing some things. Note that most IDE disks lie and always cache things. If MySQL is doing fsync's to ensure the data is on disk, the ATA disks can seem faster, but aren't as save and reliable than SCSI disks. There are many reasons one uses SCSI over IDE disks. "Raw" performance isn't necessarily one of them. Summary: please try an IDE disk in the Opteron machine. Preferable pull the disk out of the Xeon, put it in the Opteron and re-run your benchmark. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Thu Jun 23 14:07:01 2005 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 1A2D416A41C for ; Thu, 23 Jun 2005 14:07:01 +0000 (GMT) (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 BAF0343D53 for ; Thu, 23 Jun 2005 14:07:00 +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 1A3B1B80C for ; Thu, 23 Jun 2005 10:06:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <3.0.1.32.20050622163104.00a7b0c8@pop.redshift.com> References: <3.0.1.32.20050622160137.00a87c38@pop.redshift.com> <3.0.1.32.20050622104159.00a55450@pop.redshift.com> <3.0.1.32.20050622160137.00a87c38@pop.redshift.com> <3.0.1.32.20050622163104.00a7b0c8@pop.redshift.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65A56146-20F8-4664-ADF2-B20219209FD6@khera.org> Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Thu, 23 Jun 2005 10:06:56 -0400 To: freebsd-amd64 List X-Mailer: Apple Mail (2.730) Subject: Re: Slower MySQL inserts for AMD64/Opteron? 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, 23 Jun 2005 14:07:01 -0000 On Jun 22, 2005, at 7:31 PM, ray@redshift.com wrote: > BTW, I did not compile in Linux threads on either machine and I > don't believe > they are there by default. > > linuxthreads is not an even option on amd64 Vivek Khera, Ph.D. +1-301-869-4449 x806 From owner-freebsd-amd64@FreeBSD.ORG Thu Jun 23 15:56:50 2005 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 059BE16A41C for ; Thu, 23 Jun 2005 15:56:50 +0000 (GMT) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EE6343D53 for ; Thu, 23 Jun 2005 15:56:49 +0000 (GMT) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr1.xs4all.nl (8.13.3/8.13.3) with ESMTP id j5NFulu2034345; Thu, 23 Jun 2005 17:56:48 +0200 (CEST) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 183AF617F; Thu, 23 Jun 2005 17:56:47 +0200 (CEST) Date: Thu, 23 Jun 2005 17:56:47 +0200 From: Roland Smith To: "Morten A. Middelthon" Message-ID: <20050623155647.GD59771@slackbox.xs4all.nl> Mail-Followup-To: "Morten A. Middelthon" , freebsd-amd64@freebsd.org References: <20050623130010.GA74413@freenix.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9crTWz/Z+Zyzu20v" Content-Disposition: inline In-Reply-To: <20050623130010.GA74413@freenix.no> User-Agent: Mutt/1.4.2.1i X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-amd64@freebsd.org Subject: Re: mtx 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, 23 Jun 2005 15:56:50 -0000 --9crTWz/Z+Zyzu20v Content-Type: multipart/mixed; boundary="uxuisgdDHaNETlh8" Content-Disposition: inline --uxuisgdDHaNETlh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 23, 2005 at 03:00:10PM +0200, Morten A. Middelthon wrote: > Hi, >=20 > does anyone know the status of mtx on amd64? It's still marked as broken = on > ia64, sparc64 and amd64. I installed the i386-version via the precompiled > package, but it doesn't seem to be working properly, although that might = be > related to other issues.=20 The mtx package tries to use a processor flag that's invalid on anything but x86. Try applying the enclosed patch to the port. With this patch, it compiles cleanly. I can't test it because I haven't got any SCSI stuff :-) If it works, please submit a PR. Roland --=20 R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt --uxuisgdDHaNETlh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mtx.diff" Content-Transfer-Encoding: quoted-printable diff -urN mtx.orig/Makefile mtx/Makefile --- mtx.orig/Makefile Thu Mar 10 14:55:14 2005 +++ mtx/Makefile Thu Jun 23 17:42:59 2005 @@ -19,10 +19,4 @@ GNU_CONFIGURE=3D yes MAN1=3D loaderinfo.1 mtx.1 tapeinfo.1 scsitape.1 =20 -.include - -.if ${ARCH} =3D=3D "ia64" || ${ARCH} =3D=3D "sparc64" || ${ARCH} =3D=3D "a= md64" -BROKEN=3D "Does not compile on ia64, sparc64 and amd64" -.endif - -.include +.include diff -urN mtx.orig/files/patch-Makefile.in mtx/files/patch-Makefile.in --- mtx.orig/files/patch-Makefile.in Fri Feb 7 09:39:23 2003 +++ mtx/files/patch-Makefile.in Thu Jun 23 17:50:54 2005 @@ -1,14 +1,16 @@ ---- Makefile.in.orig Fri Feb 7 09:29:39 2003 -+++ Makefile.in Fri Feb 7 09:31:26 2003 -@@ -43,7 +43,11 @@ - # FreeBSD on x86... +--- Makefile.in.orig Wed Oct 2 18:55:29 2002 ++++ Makefile.in Thu Jun 23 17:50:34 2005 +@@ -40,11 +40,10 @@ + endif +=20 + # +-# FreeBSD on x86... ++# FreeBSD # ifeq ($(TARGET),freebsd86) -+ifeq ($(ARCH), alpha) -+CFLAGS +=3D -+else - CFLAGS +=3D -m486 -+endif - CPPFLAGS +=3D -I/usr/src/linux/include -DLONG_PRINT_REQUEST_SENSE=3D1 +-CFLAGS +=3D -m486 +-CPPFLAGS +=3D -I/usr/src/linux/include -DLONG_PRINT_REQUEST_SENSE=3D1 ++CPPFLAGS +=3D -DLONG_PRINT_REQUEST_SENSE=3D1 LIBS +=3D -lcam endif +=20 --uxuisgdDHaNETlh8-- --9crTWz/Z+Zyzu20v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCutu/EnfvsMMhpyURAq3CAJ9AyJwNC6I2ObkLSa2xZQIyaD5aVwCaAzYl E96DamFDOVHIgM8cn9kyxIU= =05bk -----END PGP SIGNATURE----- --9crTWz/Z+Zyzu20v-- From owner-freebsd-amd64@FreeBSD.ORG Thu Jun 23 18:50:24 2005 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 08A7916A41C for ; Thu, 23 Jun 2005 18:50:24 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF46543D49 for ; Thu, 23 Jun 2005 18:50:23 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 4938A970BE; Thu, 23 Jun 2005 11:50:23 -0700 (PDT) Message-Id: <3.0.1.32.20050623115036.00acd818@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Thu, 23 Jun 2005 11:50:36 -0700 To: freebsd-amd64@FreeBSD.org From: ray@redshift.com In-Reply-To: <20050623134319.GA43842@dragon.NUXI.org> References: <3.0.1.32.20050622104159.00a55450@pop.redshift.com> <3.0.1.32.20050622104159.00a55450@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-amd64@FreeBSD.org Subject: Re: Slower MySQL inserts for AMD64/Opteron? 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, 23 Jun 2005 18:50:24 -0000 Thanks, I will do that :-) When you speak about IDE/ATA, does that apply to SATA as well? Or just PATA? Ray At 06:43 AM 6/23/2005 -0700, David O'Brien wrote: | On Wed, Jun 22, 2005 at 10:41:59AM -0700, ray@redshift.com wrote: | > I did some benchmarks recently on a single 2.4Ghz Xeon against a Dual | > 246 Opteron and noticed when it came to MySQL inserts, the single Xeon | > was about 20% faster on inserts (and it actually had a slower hard | > drive, IDE vs SATA). The interesting thing is that the Dual Opterons | > was twice as fast retrieving the data using selects. | .. | > The Xeon was running 5.3/i386. I believe the AMD was running 5.4/AMD64. | | Note that in 5.4, the ATA subsystem runs without the Big-GIANT-Lock. CAM | (SCSI subsystem) still grabs GIANT. For a system with a single activity | going on (such as yours), I feel ATA can "out perform" SCSI doing some | things. Note that most IDE disks lie and always cache things. If MySQL | is doing fsync's to ensure the data is on disk, the ATA disks can seem | faster, but aren't as save and reliable than SCSI disks. There are many | reasons one uses SCSI over IDE disks. "Raw" performance isn't | necessarily one of them. | | Summary: please try an IDE disk in the Opteron machine. Preferable pull | the disk out of the Xeon, put it in the Opteron and re-run your | benchmark. | | -- | -- David (obrien@FreeBSD.org) | | From owner-freebsd-amd64@FreeBSD.ORG Thu Jun 23 18:50:59 2005 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 2EBF316A41C for ; Thu, 23 Jun 2005 18:50:59 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12A7B43D1F for ; Thu, 23 Jun 2005 18:50:59 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 41D72970BE; Thu, 23 Jun 2005 11:50:53 -0700 (PDT) Message-Id: <3.0.1.32.20050623115107.00acd818@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Thu, 23 Jun 2005 11:51:07 -0700 To: Vivek Khera , freebsd-amd64 List From: ray@redshift.com In-Reply-To: <65A56146-20F8-4664-ADF2-B20219209FD6@khera.org> References: <3.0.1.32.20050622163104.00a7b0c8@pop.redshift.com> <3.0.1.32.20050622160137.00a87c38@pop.redshift.com> <3.0.1.32.20050622104159.00a55450@pop.redshift.com> <3.0.1.32.20050622160137.00a87c38@pop.redshift.com> <3.0.1.32.20050622163104.00a7b0c8@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Subject: Re: Slower MySQL inserts for AMD64/Opteron? 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, 23 Jun 2005 18:50:59 -0000 :-) At 10:06 AM 6/23/2005 -0400, Vivek Khera wrote: | | On Jun 22, 2005, at 7:31 PM, ray@redshift.com wrote: | | > BTW, I did not compile in Linux threads on either machine and I | > don't believe | > they are there by default. | > | > | | linuxthreads is not an even option on amd64 | | Vivek Khera, Ph.D. | +1-301-869-4449 x806 | | | _______________________________________________ | 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 Thu Jun 23 19:15:29 2005 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 D2F7616A41C; Thu, 23 Jun 2005 19:15:29 +0000 (GMT) (envelope-from freebsd@epicoftimewasted.com) Received: from anya.eboundary.com (anya.eboundary.com [69.90.127.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id A22CA43D1D; Thu, 23 Jun 2005 19:15:25 +0000 (GMT) (envelope-from freebsd@epicoftimewasted.com) Received: from epicofti by anya.eboundary.com with local (Exim 4.51 (FreeBSD)) id 1DlXFy-0005oo-1m; Thu, 23 Jun 2005 15:20:58 -0400 Received: from 127.0.0.1 ([127.0.0.1]) (SquirrelMail authenticated user freebsd@epicoftimewasted.com) by www.epicoftimewasted.com with HTTP; Thu, 23 Jun 2005 15:20:58 -0400 (EDT) Message-ID: <2707.127.0.0.1.1119554458.squirrel@www.epicoftimewasted.com> Date: Thu, 23 Jun 2005 15:20:58 -0400 (EDT) From: "Ryan R." To: freebsd-amd64@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - anya.eboundary.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [1018 1019] / [26 6] X-AntiAbuse: Sender Address Domain - epicoftimewasted.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org Subject: Sound/volume control problem 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, 23 Jun 2005 19:15:30 -0000 I'm running 6-CURRENT/amd64 dated Wed Jun 22 11:41:19 PDT 2005, using a Soundblaster Live! sound card. I have "device sound" and "device snd_emu10k1" built into the kernel. The card is detected by the kernel, and the sound appears to work just fine. The problem is the volume control doesn't work. XMMS for example, gives me this error message when adjusting the volume (mixer: vol): WARNING pid 88402 (xmms): ioctl sign-extension ioctl ffffffffc0044d00 And when telling XMMS that volume controls pcm rather than master vol: WARNING pid 88405 (xmms): ioctl sign-extension ioctl ffffffffc0044d04 In an attempt to rule out XMMS as the problem, I also installed mplayer. Mplayer doesn't spit out an error message when adjusting the volume, but the volume stays at a constant level. I've checked the output of mixer, and that sees the volume changes, but doesn't actually adjust the volume. Is this a FreeBSD error, or a user error? Is there anything that I could try to fix the problem? Thanks. Ryan From owner-freebsd-amd64@FreeBSD.ORG Thu Jun 23 19:35:51 2005 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 5086116A41C for ; Thu, 23 Jun 2005 19:35:51 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82ADB43D48 for ; Thu, 23 Jun 2005 19:35:50 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 93454 invoked by uid 89); 23 Jun 2005 19:34:28 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 23 Jun 2005 19:34:28 -0000 Date: Thu, 23 Jun 2005 21:35:42 +0200 From: Oliver Lehmann To: "Ryan R." Message-Id: <20050623213542.001e162d.lehmann@ans-netz.de> In-Reply-To: <2707.127.0.0.1.1119554458.squirrel@www.epicoftimewasted.com> References: <2707.127.0.0.1.1119554458.squirrel@www.epicoftimewasted.com> X-Mailer: Sylpheed version 2.0.0beta3 (GTK+ 2.6.8; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Sound/volume control problem 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, 23 Jun 2005 19:35:51 -0000 Ryan R. wrote: > Is this a FreeBSD error, or a user error? Is there anything that I could > try to fix the problem? Thanks. That is a xmms error. In Output/esd/mixer.c and Output/OSS/mixer.c, ioctl is called with a int declared request argument. Regarding to the ioctl manpage it has to be long instead of int. On 32bit platforms that doesn't matter since int has the same size than long has. On 64bit platforms int and long differs. I made two patches to multimedia/beep-media-player which are fixing those problems in bmp. They should be easily adoptable for xmms since bmp is a xmms fork. for reference: multimedia/beep-media-player/files/patch-Output-esd-mixer.c multimedia/beep-media-player/files/patch-Output-OSS-mixer.c -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-amd64@FreeBSD.ORG Thu Jun 23 20:44:11 2005 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 3321C16A41C for ; Thu, 23 Jun 2005 20:44:11 +0000 (GMT) (envelope-from freebsd@epicoftimewasted.com) Received: from anya.eboundary.com (anya.eboundary.com [69.90.127.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id F378343D58 for ; Thu, 23 Jun 2005 20:44:10 +0000 (GMT) (envelope-from freebsd@epicoftimewasted.com) Received: from epicofti by anya.eboundary.com with local (Exim 4.51 (FreeBSD)) id 1DlYds-000BlD-0k; Thu, 23 Jun 2005 16:49:44 -0400 Received: from 127.0.0.1 ([127.0.0.1]) (SquirrelMail authenticated user freebsd@epicoftimewasted.com) by www.epicoftimewasted.com with HTTP; Thu, 23 Jun 2005 16:49:44 -0400 (EDT) Message-ID: <3239.127.0.0.1.1119559784.squirrel@www.epicoftimewasted.com> In-Reply-To: <20050623213542.001e162d.lehmann@ans-netz.de> References: <2707.127.0.0.1.1119554458.squirrel@www.epicoftimewasted.com> <20050623213542.001e162d.lehmann@ans-netz.de> Date: Thu, 23 Jun 2005 16:49:44 -0400 (EDT) From: "Ryan R." To: "Oliver Lehmann" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - anya.eboundary.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [1018 1019] / [26 6] X-AntiAbuse: Sender Address Domain - epicoftimewasted.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-amd64@freebsd.org Subject: [FIXED] Sound/volume control problem 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, 23 Jun 2005 20:44:11 -0000 Ok, it's time to open mouth and insert foot I believe. I've long since lost the manual for this sound card, and have ripped the computer apart so many times since the manual was last seen. To make a long, rather embarrassing story short, I had my speakers hooked up incorrectly. I hate when the solution is so simple that you think it could never be that easy. I believe a wise man once said... "Doh!" Thanks though, I had never heard of bmp, and at first glance it looks pretty nice. I'll have to see if I like it more than xmms. Ryan > Ryan R. wrote: > >> Is this a FreeBSD error, or a user error? Is there anything that I >> could >> try to fix the problem? Thanks. > > That is a xmms error. In Output/esd/mixer.c and Output/OSS/mixer.c, ioctl > is called with a int declared request argument. Regarding to the ioctl > manpage it has to be long instead of int. On 32bit platforms that doesn't > matter since int has the same size than long has. On 64bit platforms int > and long differs. I made two patches to multimedia/beep-media-player > which are fixing those problems in bmp. They should be easily adoptable > for xmms since bmp is a xmms fork. > > for reference: > > multimedia/beep-media-player/files/patch-Output-esd-mixer.c > multimedia/beep-media-player/files/patch-Output-OSS-mixer.c > > -- > Oliver Lehmann > http://www.pofo.de/ > http://wishlist.ans-netz.de/ > From owner-freebsd-amd64@FreeBSD.ORG Thu Jun 23 22:19:02 2005 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 8632B16A41C for ; Thu, 23 Jun 2005 22:19:02 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 311CD43D4C for ; Thu, 23 Jun 2005 22:19:02 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j5NMJ0J8067385; Fri, 24 Jun 2005 00:19:00 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j5NMIuNC067382; Thu, 23 Jun 2005 18:18:56 -0400 (EDT) (envelope-from cracauer) Date: Thu, 23 Jun 2005 18:18:56 -0400 From: Martin Cracauer To: Jose M Rodriguez Message-ID: <20050623181856.A67269@cons.org> References: <200506131616.j5DGGDfr067534@lurza.secnetix.de> <200506132038.25975.josemi@redesjm.local> <200506131147.50300.peter@wemm.org> <200506132102.56346.josemi@redesjm.local> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <200506132102.56346.josemi@redesjm.local>; from josemi@freebsd.jazztel.es on Mon, Jun 13, 2005 at 09:02:55PM +0200 Cc: freebsd-amd64@freebsd.org Subject: Re: Athlon64 board with ECC 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: Thu, 23 Jun 2005 22:19:02 -0000 Jose M Rodriguez wrote on Mon, Jun 13, 2005 at 09:02:55PM +0200: > El Lunes, 13 de Junio de 2005 20:47, Peter Wemm escribi: > > On Monday 13 June 2005 11:38 am, Jose M Rodriguez wrote: > > > El Lunes, 13 de Junio de 2005 18:16, Oliver Fromme escribi: > > > > Hi, > > > > > > > > I'm currently evaluating possibilities to upgrade to a > > > > 64bit system (preferably AMD). I would like to get a > > > > single-processor Athlon64 system, no Opteron, because of > > > > heat, noise and power consumption (and price). > > > > > > > > Furthermore, I would like to have ECC RAM. However, it > > > > seems that this requirement is not easy to meet. > > > > > > > > So far, Google told me that the Athlon64 and the socket939 > > > > basically support ECC. However, it also requires support > > > > in the chipset and in the BIOS. I've looked at a few > > > > random socket939 board specs, and all of them allow the > > > > use of ECC memory, _but_ they don't support using it for > > > > actual error correction, i.e. they treat 72bit DIMMs like > > > > 64bit DIMMs and ignore the ECC part. This is not what I > > > > want, of course. > > > > > > > > Now my question is: Are there any Athlon64 (s939) boards > > > > that really support ECC RAM? Any recommendations? > > > > > > As far I know, only nvidia nforce4 have support for this. But this > > > may get you into problems with lan and disk (SATA). > > > > The system chipset has nothing to do with ECC support. Unlike on > > Intel systems, memory is connected to the CPU, not the chipset. The > > chipset (nforce vs via vs whatever) has no say in the matter. > > Well, I only see this in new nvidia nforce4 based boards. I also think > this is more a bios problem. My NVidia NForce 3 250GB board (socket 754) did support ECC (unbuffered). I had way too much trouble with that board and got a via-based socket 754 board - which doesn't appear to support ECC. While the chipset might not be able to mess with it the mainboard can certainly omit lanes required. And I suppose the BIOS needs to support it, too, although it is not clear to me how ECC exceptions are supposed to be routed anyway. Clearly some chip not being CPU or RAM needs to have a say in the exception delivery? Anybody understands how this works? I am switching to socket 940 with AMD chipset now, I'm fed up with that NVidia mess and toy chipsets not supporting ECC (that Via-based board that I have, Abit K8V-pro, I have also seems to have omitted any hardware for temperature/fan monitoring). Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-amd64@FreeBSD.ORG Thu Jun 23 22:37:43 2005 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 68E3A16A41C for ; Thu, 23 Jun 2005 22:37:43 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3B1B43D4C for ; Thu, 23 Jun 2005 22:37:42 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j5NMbgcs067664 for ; Fri, 24 Jun 2005 00:37:42 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j5NMbg2c067663 for freebsd-amd64@freebsd.org; Thu, 23 Jun 2005 18:37:42 -0400 (EDT) (envelope-from cracauer) Date: Thu, 23 Jun 2005 18:37:41 -0400 From: Martin Cracauer To: freebsd-amd64@freebsd.org Message-ID: <20050623183741.A67399@cons.org> References: <200506131616.j5DGGDfr067534@lurza.secnetix.de> <20050613192009.GA4323@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050613192009.GA4323@dragon.NUXI.org>; from obrien@freebsd.org on Mon, Jun 13, 2005 at 12:20:09PM -0700 Subject: AMD64 models power consumption (Was: Athlon64 board with ECC 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: Thu, 23 Jun 2005 22:37:43 -0000 "David O'Brien" wrote on Mon, Jun 13, 2005 at 12:20:09PM -0700: > On Mon, Jun 13, 2005 at 06:16:13PM +0200, Oliver Fromme wrote: > > I'm currently evaluating possibilities to upgrade to a > > 64bit system (preferably AMD). I would like to get a > > single-processor Athlon64 system, no Opteron, because of > > heat, noise and power consumption (and price). > > There is no difference between Athlon64 and Opteron with respect to heat, > noise and power consumption. There is yes a price difference. That is not strictly true for the idle case. The Opterons only got cool'n'quiet with the E steppings (also switched to 90 nm process), which are brand new and rare. Practially every Opteron in common use and currently sold is the C0 stepping or lower (130 nm) which takes up substancially more power than any of the Athlon 64s in the idle case. My socket 754 newcastle 3400+ is one of my least power consuming machines when idle, my work Opterons 248 and 250 use a lot more in the same situation with the same OS. If you have two Opterons in one box this becomes uncomfortable quickly. If you get a venice or San Diego core (Athlon 64) you are even better off (in that case idle and busy). If you pay (much) more, the Opterons come in two grades of low power models (where the low power is for the busy case). Regarding fans and prices, I think the fans shipped with Opteron retail sets are of higher quality (that kit is reltively more expensive). The Athlon 64 retail kit fans are very quiet and nice for about a year (much better than Athlon XP fans were), but then they start mimicking aircraft carrier flight decks. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-amd64@FreeBSD.ORG Fri Jun 24 05:53:23 2005 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 B495516A41C for ; Fri, 24 Jun 2005 05:53:23 +0000 (GMT) (envelope-from morten@atreides.freenix.no) Received: from freenix.no (atreides.freenix.no [212.33.142.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC06543D48 for ; Fri, 24 Jun 2005 05:53:12 +0000 (GMT) (envelope-from morten@atreides.freenix.no) Received: from atreides.freenix.no (localhost [127.0.0.1]) by freenix.no (8.13.1/8.13.1) with ESMTP id j5O5pCQk087142; Fri, 24 Jun 2005 07:52:01 +0200 (CEST) (envelope-from morten@atreides.freenix.no) Received: (from morten@localhost) by atreides.freenix.no (8.13.1/8.13.1/Submit) id j5O5p6iP087141; Fri, 24 Jun 2005 07:51:06 +0200 (CEST) (envelope-from morten) Date: Fri, 24 Jun 2005 07:51:06 +0200 From: "Morten A. Middelthon" To: rsmith@xs4all.nl Message-ID: <20050624055106.GA86765@freenix.no> References: <20050623130010.GA74413@freenix.no> <20050623155647.GD59771@slackbox.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <20050623155647.GD59771@slackbox.xs4all.nl> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://freenix.no/~morten/pgp.txt X-PGP-Key-FingerPrint: D48B 5C4E 1590 7DE6 08A0 6539 BECC F62E 829F DF6A X-Operating-System: FreeBSD 4.11-RELEASE-p2 X-Warning: So cunning you could brush your teeth with it. X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on atreides.freenix.no X-Virus-Status: Clean Cc: freebsd-amd64@freebsd.org Subject: Re: mtx 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, 24 Jun 2005 05:53:23 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 23, 2005 at 05:56:47PM +0200, Roland Smith wrote: > On Thu, Jun 23, 2005 at 03:00:10PM +0200, Morten A. Middelthon wrote: > > Hi, > >=20 > > does anyone know the status of mtx on amd64? It's still marked as broke= n on > > ia64, sparc64 and amd64. I installed the i386-version via the precompil= ed > > package, but it doesn't seem to be working properly, although that migh= t be > > related to other issues.=20 >=20 > The mtx package tries to use a processor flag that's invalid on anything > but x86. Try applying the enclosed patch to the port. With this patch, > it compiles cleanly. I can't test it because I haven't got any SCSI > stuff :-) >=20 > If it works, please submit a PR. Hi, thanks for the quick reply and help. The patch doesn't work properly on mtx/Makefile, but I manually commented out "if ${ARCH} =3D=3D "ia64" || ${A= RCH} =3D=3D "sparc64" || ${ARCH} =3D=3D "amd64"" etc. However, mtx/files/patch-Makefile.in patched correctly, and it compiled without warnings. The program runs like it should too. F.ex: mtx -f /dev/pass1 inquiry Product Type: Medium Changer Vendor ID: 'DELL ' Product ID: 'PV-122T ' Revision: 'K17r' Attached Changer: No In my previous attempts I would get error messages with something like "Inappropriate ioctl for device", but I haven't gotten anything like this so far. Excellent! Thank you very much for your help.=20 with regards, --=20 Morten A. Middelthon Wenn ist das Nunstruck git und Slotermeyer? Ja! ... Beiherhund das Oder die Flipperwaldt gersput! --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFCu59Kvsz2LoKf32oRApSxAKCBfK7Q2cLCh6aqTmkFoqfcPAaOQwCfaaV1 Yam0KfJbFh/n13m72qLnV4M= =GqHT -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-amd64@FreeBSD.ORG Fri Jun 24 07:10:20 2005 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 C933F16A41C for ; Fri, 24 Jun 2005 07:10:20 +0000 (GMT) (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 48B3543D5D for ; Fri, 24 Jun 2005 07:10:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5O7A7IV063605 for ; Fri, 24 Jun 2005 07:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5O7A7Op063604; Fri, 24 Jun 2005 07:10:07 GMT (envelope-from gnats) Resent-Date: Fri, 24 Jun 2005 07:10:07 GMT Resent-Message-Id: <200506240710.j5O7A7Op063604@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, "Morten A. Middelthon" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AD1D16A41C for ; Fri, 24 Jun 2005 07:07:42 +0000 (GMT) (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 66D4343D53 for ; Fri, 24 Jun 2005 07:07:42 +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 j5O77gTe080019 for ; Fri, 24 Jun 2005 07:07:42 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j5O77fsb080018; Fri, 24 Jun 2005 07:07:41 GMT (envelope-from nobody) Message-Id: <200506240707.j5O77fsb080018@www.freebsd.org> Date: Fri, 24 Jun 2005 07:07:41 GMT From: "Morten A. Middelthon" To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/82599: ports/misc/mtx wont compile 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, 24 Jun 2005 07:10:20 -0000 >Number: 82599 >Category: amd64 >Synopsis: ports/misc/mtx wont compile on amd64 >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 Jun 24 07:10:06 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Morten A. Middelthon >Release: 5.4-RELEASE >Organization: CoreTrek Development AS >Environment: FreeBSD kepler.coretrek.no 5.4-RELEASE FreeBSD 5.4-RELEASE #2: Fri Jun 17 16:41:08 CEST 2005 morten@kepler.coretrek.no:/usr/src/sys/amd64/compile/kepler amd64 >Description: The port misc/mtx would not compile on amd64. The port is marked as broken for the amd64, ia64 and sparc64 platform. Output from make: ===> Building for mtx-1.2.17rel_1 cc -O -pipe -m486 -DVERSION="\"1.2.17rel\"" -I/usr/src/linux/include -DLONG_PRINT_REQUEST_SENSE=1 -c -o mtx.o mtx.c `-m486' is deprecated. Use `-march=i486' or `-mtune=i486' instead. mtx.c:1: error: CPU you selected does not support x86-64 instruction set gmake: *** [mtx.o] Error 1 *** Error code 2 Stop in /usr/ports/misc/mtx. >How-To-Repeat: Apply the following patch to /usr/ports/misc/mtx/Makefile: http://coretrekker.com/~morten/Makefile.diff Then run 'make' in /usr/ports/misc/mtx >Fix: Apply the following patches: in /usr/ports/misc http://coretrekker.com/~morten/mtx.diff (This patch was created by Roland Smith ) in /usr/ports/misc/mtx http://coretrekker.com/~morten/Makefile.diff The program will now compile and run correctly >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Fri Jun 24 13:20:03 2005 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 2D6E116A41C for ; Fri, 24 Jun 2005 13:20:03 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08A1F43D1F for ; Fri, 24 Jun 2005 13:20:03 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5ODK2e8065593; Fri, 24 Jun 2005 06:20:02 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5ODK2sO065592; Fri, 24 Jun 2005 06:20:02 -0700 (PDT) (envelope-from obrien) Date: Fri, 24 Jun 2005 06:20:02 -0700 From: "David O'Brien" To: ray@redshift.com Message-ID: <20050624132002.GA65546@dragon.NUXI.org> References: <3.0.1.32.20050622104159.00a55450@pop.redshift.com> <3.0.1.32.20050622104159.00a55450@pop.redshift.com> <3.0.1.32.20050623115036.00acd818@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.1.32.20050623115036.00acd818@pop.redshift.com> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@FreeBSD.org Subject: Re: Slower MySQL inserts for AMD64/Opteron? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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: Fri, 24 Jun 2005 13:20:03 -0000 [ please do not top post to FreeBSD lists ] On Thu, Jun 23, 2005 at 11:50:36AM -0700, ray@redshift.com wrote: > At 06:43 AM 6/23/2005 -0700, David O'Brien wrote: > | Note that in 5.4, the ATA subsystem runs without the Big-GIANT-Lock. CAM > | (SCSI subsystem) still grabs GIANT. For a system with a single activity > | going on (such as yours), I feel ATA can "out perform" SCSI doing some > | things. [..] > > Thanks, I will do that :-) When you speak about IDE/ATA, does that apply to > SATA as well? Or just PATA? It applies equaly to SATA and PATA. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Fri Jun 24 13:31:32 2005 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 60F4C16A41C for ; Fri, 24 Jun 2005 13:31:32 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 129E743D1D for ; Fri, 24 Jun 2005 13:31:32 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5ODVISc065842; Fri, 24 Jun 2005 06:31:19 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5ODVHms065841; Fri, 24 Jun 2005 06:31:17 -0700 (PDT) (envelope-from obrien) Date: Fri, 24 Jun 2005 06:31:17 -0700 From: "David O'Brien" To: Martin Cracauer Message-ID: <20050624133117.GB65546@dragon.NUXI.org> References: <200506131616.j5DGGDfr067534@lurza.secnetix.de> <20050613192009.GA4323@dragon.NUXI.org> <20050623183741.A67399@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050623183741.A67399@cons.org> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: AMD64 models power consumption (Was: Athlon64 board with ECC support?) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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: Fri, 24 Jun 2005 13:31:32 -0000 On Thu, Jun 23, 2005 at 06:37:41PM -0400, Martin Cracauer wrote: > "David O'Brien" wrote on Mon, Jun 13, 2005 at 12:20:09PM -0700: > > On Mon, Jun 13, 2005 at 06:16:13PM +0200, Oliver Fromme wrote: > > > I'm currently evaluating possibilities to upgrade to a > > > 64bit system (preferably AMD). I would like to get a > > > single-processor Athlon64 system, no Opteron, because of > > > heat, noise and power consumption (and price). > > > > There is no difference between Athlon64 and Opteron with respect to heat, > > noise and power consumption. There is yes a price difference. > > That is not strictly true for the idle case. The Opterons only got > cool'n'quiet with the E steppings (also switched to 90 nm process), > which are brand new and rare. Opterons grew PowerNow (proper term for the Opteron functionality) with revision 'CG'. It just happens that PowerNow supporting BIOS's came out with the revision E launch [as motherboard vendors had to rev. their BIOS]. The 130nm -> 90nm was revision D. > Practially every Opteron in common use and currently sold is the C0 > stepping or lower (130 nm) which takes up substancially more power > than any of the Athlon 64s in the idle case. Not if you are not using Cool-n-quiet or PowerNow. A 512KB L2 Athlon64 is of course going to run cooler than a 1MB L2 Opteron or Athlon64 with 1MB L2. But the Opteron and 1MB L2 Athlon64 of the same silicon revision has the same heat production. > My socket 754 newcastle 3400+ is one of my least power consuming > machines when idle, my work Opterons 248 and 250 use a lot more in the > same situation with the same OS. You're comparing either a 2.2ghz 1MB L2 or 2.4ghz 512KB L2 CPU with a 2.4ghz 1MB L2 CPU. Naturally the latter will run hotter and use more power. You're also probably comparing revision C0 with revision CG. (I can never keep straight the core names, AMD CPU designers and SW engineers don't use core names as they often are process changes) You're also getting more things than just CPU cores involved in your comparison. 2P Opteron boards have more functionality, more power planes, most likely less efficient power supply, etc... > If you have two Opterons in one box > this becomes uncomfortable quickly. If you get a venice or San Diego > core (Athlon 64) you are even better off (in that case idle and busy). I have to disagree - my workstation at both home and work are dual-processor Opterons. They don't run uncomfortably hot. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Fri Jun 24 13:35:14 2005 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 04CF816A41C for ; Fri, 24 Jun 2005 13:35:14 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id C790C43D1D for ; Fri, 24 Jun 2005 13:35:13 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5ODYw7c065981; Fri, 24 Jun 2005 06:34:58 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5ODYvGk065980; Fri, 24 Jun 2005 06:34:57 -0700 (PDT) (envelope-from obrien) Date: Fri, 24 Jun 2005 06:34:57 -0700 From: "David O'Brien" To: Martin Cracauer Message-ID: <20050624133457.GC65546@dragon.NUXI.org> References: <200506131616.j5DGGDfr067534@lurza.secnetix.de> <200506132038.25975.josemi@redesjm.local> <200506131147.50300.peter@wemm.org> <200506132102.56346.josemi@redesjm.local> <20050623181856.A67269@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050623181856.A67269@cons.org> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-amd64@freebsd.org Subject: Re: Athlon64 board with ECC support? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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: Fri, 24 Jun 2005 13:35:14 -0000 On Thu, Jun 23, 2005 at 06:18:56PM -0400, Martin Cracauer wrote: > And I suppose the BIOS needs to support it, too, Correct. > although it is not > clear to me how ECC exceptions are supposed to be routed anyway. > Clearly some chip not being CPU or RAM needs to have a say in the > exception delivery? Anybody understands how this works? Why?? The memory controller is on the same die as the CPU. The exception is handled w/in the CPU and it never goes out to any support chip. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Fri Jun 24 13:48:32 2005 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 2113016A41C for ; Fri, 24 Jun 2005 13:48:32 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from 62-14-156-60.inversas.jazztel.es (62-14-156-60.inversas.jazztel.es [62.14.156.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77F0D43D53 for ; Fri, 24 Jun 2005 13:48:30 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) by 62-14-156-60.inversas.jazztel.es (8.13.3/8.13.3) with ESMTP id j5ODmMYj030969; Fri, 24 Jun 2005 15:48:22 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j5ODmK8J027277; Fri, 24 Jun 2005 15:48:20 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: freebsd-amd64@freebsd.org Date: Fri, 24 Jun 2005 15:48:16 +0200 User-Agent: KMail/1.8 References: <200506131616.j5DGGDfr067534@lurza.secnetix.de> <20050623181856.A67269@cons.org> <20050624133457.GC65546@dragon.NUXI.org> In-Reply-To: <20050624133457.GC65546@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200506241548.17768.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.15; VDF: 6.30.0.207; host: antares.redesjm.local) Cc: Martin Cracauer Subject: Re: Athlon64 board with ECC 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: Fri, 24 Jun 2005 13:48:32 -0000 El Viernes, 24 de Junio de 2005 15:34, David O'Brien escribi=F3: > On Thu, Jun 23, 2005 at 06:18:56PM -0400, Martin Cracauer wrote: > > And I suppose the BIOS needs to support it, too, > > Correct. > > > although it is not > > clear to me how ECC exceptions are supposed to be routed anyway. > > Clearly some chip not being CPU or RAM needs to have a say in the > > exception delivery? Anybody understands how this works? > > Why?? The memory controller is on the same die as the CPU. The > exception is handled w/in the CPU and it never goes out to any > support chip. Are you sure the mem. controller in the CPU is not configured/affected=20 by GPIO bits in the southbridge? =2D- josemi From owner-freebsd-amd64@FreeBSD.ORG Fri Jun 24 14:04:40 2005 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 18D5616A41C for ; Fri, 24 Jun 2005 14:04:40 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6F1343D48 for ; Fri, 24 Jun 2005 14:04:37 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j5OE4Z3A088821; Fri, 24 Jun 2005 16:04:35 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j5OE4ZIu088820; Fri, 24 Jun 2005 10:04:35 -0400 (EDT) (envelope-from cracauer) Date: Fri, 24 Jun 2005 10:04:35 -0400 From: Martin Cracauer To: freebsd-amd64@freebsd.org Message-ID: <20050624100435.A88745@cons.org> References: <200506131616.j5DGGDfr067534@lurza.secnetix.de> <200506132038.25975.josemi@redesjm.local> <200506131147.50300.peter@wemm.org> <200506132102.56346.josemi@redesjm.local> <20050623181856.A67269@cons.org> <20050624133457.GC65546@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050624133457.GC65546@dragon.NUXI.org>; from obrien@freebsd.org on Fri, Jun 24, 2005 at 06:34:57AM -0700 Cc: Martin Cracauer Subject: Re: Athlon64 board with ECC 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: Fri, 24 Jun 2005 14:04:40 -0000 David O'Brien wrote on Fri, Jun 24, 2005 at 06:34:57AM -0700: > On Thu, Jun 23, 2005 at 06:18:56PM -0400, Martin Cracauer wrote: > > And I suppose the BIOS needs to support it, too, > > Correct. > > > although it is not > > clear to me how ECC exceptions are supposed to be routed anyway. > > Clearly some chip not being CPU or RAM needs to have a say in the > > exception delivery? Anybody understands how this works? > > Why?? The memory controller is on the same die as the CPU. The > exception is handled w/in the CPU and it never goes out to any support > chip. Hm, so what does the BIOS do if it has the ECC options, exactly? Does it set defaults in the CPU itself? If so it should be possible to inspect and mess with these settings after startup? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-amd64@FreeBSD.ORG Fri Jun 24 14:42:40 2005 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 C0CDC16A41C; Fri, 24 Jun 2005 14:42:40 +0000 (GMT) (envelope-from evantd@washington.edu) Received: from innosense.washington.edu (c-24-19-1-105.hsd1.wa.comcast.net [24.19.1.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id A242F43D48; Fri, 24 Jun 2005 14:42:40 +0000 (GMT) (envelope-from evantd@washington.edu) Received: by innosense.washington.edu (Postfix, from userid 1001) id CC67ABEF4; Fri, 24 Jun 2005 07:41:39 -0700 (PDT) Date: Fri, 24 Jun 2005 07:41:39 -0700 From: Evan Dower To: "Ryan R." Message-ID: <20050624144139.GF54283@innosense.washington.edu> References: <2707.127.0.0.1.1119554458.squirrel@www.epicoftimewasted.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2707.127.0.0.1.1119554458.squirrel@www.epicoftimewasted.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Sound/volume control problem 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, 24 Jun 2005 14:42:40 -0000 I am reminded of Thu, Jun 23, 2005 at 03:20:58PM -0400 when Ryan R. said: > I'm running 6-CURRENT/amd64 dated Wed Jun 22 11:41:19 PDT 2005, using a > Soundblaster Live! sound card. I have "device sound" and "device > snd_emu10k1" built into the kernel. The card is detected by the kernel, > and the sound appears to work just fine. The problem is the volume > control doesn't work. XMMS for example, gives me this error message when > adjusting the volume (mixer: vol): > > WARNING pid 88402 (xmms): ioctl sign-extension ioctl ffffffffc0044d00 > > And when telling XMMS that volume controls pcm rather than master vol: > > WARNING pid 88405 (xmms): ioctl sign-extension ioctl ffffffffc0044d04 > > In an attempt to rule out XMMS as the problem, I also installed mplayer. > Mplayer doesn't spit out an error message when adjusting the volume, but > the volume stays at a constant level. I've checked the output of mixer, > and that sees the volume changes, but doesn't actually adjust the volume. > > Is this a FreeBSD error, or a user error? Is there anything that I could > try to fix the problem? Thanks. > > Ryan Have you tried using plain-old mixer to change the volume? I wonder if it might give other useful information. # adjust the master volume a couple times mixer 75 mixer 100 # adjust the pcm volume a couple times mixer pcm 100 mixer pcm 75 -- Evan Dower Software Development Engineer Amazon.com, Inc. Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D From owner-freebsd-amd64@FreeBSD.ORG Fri Jun 24 17:44:51 2005 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 D6C8316A41C for ; Fri, 24 Jun 2005 17:44:51 +0000 (GMT) (envelope-from noble.hays@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FEF743D48 for ; Fri, 24 Jun 2005 17:44:49 +0000 (GMT) (envelope-from noble.hays@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so1249198nzp for ; Fri, 24 Jun 2005 10:44:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=XE2MhRonoo3Ba7zVFQ9stPjChu9KFOi8ZiSHz2pYondCCPqkDw5kCmzlN/NcGMX/59oxLuFgKR+g/nORDAdhJ2EBXU2Q2mNsbKTODVqgSFZfQrfGYKrAFv2Wp1JPU9Rs8wrU6LUbPVZNEjjG2dMzPjiaoFrqjp4ETdCSnky+G9M= Received: by 10.36.222.5 with SMTP id u5mr1187390nzg; Fri, 24 Jun 2005 10:44:46 -0700 (PDT) Received: from ?192.168.0.10? ([68.107.212.249]) by mx.gmail.com with ESMTP id 5sm3248429nzk.2005.06.24.10.44.46; Fri, 24 Jun 2005 10:44:46 -0700 (PDT) Message-ID: <42BC4681.80009@gmail.com> Date: Fri, 24 Jun 2005 12:44:33 -0500 From: Noble Hays User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050621) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: AN8 motherboard SATA issues? 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, 24 Jun 2005 17:44:51 -0000 Well, My father and I are attempteing to move to the 64 bit universe, and so far, no good. We recived our purchase from new egg and now have a machine with the following specs: A-Bit AN8 Guru board AMD 64 3000+ NVidia GeForce 6600 PCI-E 512 DDR 400 2x Segate SATA 150 80.0GB Harddrives 1 120GB Segate Harddrive(not recived yet) AOpen DVD+-RW DL I downloaded the AMD64 disk1 iso off of FreeBSD's main site, burned it succesfully of my old machine, and tried to install... the CD Loader worked, then the Bootloader, then I selected the default at the prompt, and it started detecting hardware... Here's the problem... It freezes up after detecting the SATA drives and it moves through the detections quickly so I can't read any of the warnings... when it freezes scroll lock doesn't allow me to look back and see if everything else is working. I had a i386 5.4 disk, and tried it just to make sure there wasn't a burn issue, it sticks at exactly the same spot. I'm fairly new to freebsd, and me and dad are both new to the 64bit systems. So this maybe an id-ten-t user problem, but if someone has some suggestions, I'd like to try them. Thanks for your patience. From owner-freebsd-amd64@FreeBSD.ORG Fri Jun 24 18:55:29 2005 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 ADAB416A41C for ; Fri, 24 Jun 2005 18:55:29 +0000 (GMT) (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 8B1AE43D48 for ; Fri, 24 Jun 2005 18:55:29 +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 76B702A909 for ; Fri, 24 Jun 2005 11:55:29 -0700 (PDT) (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 38A7CE2B3 for ; Fri, 24 Jun 2005 11:55:29 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.3/8.13.1) with ESMTP id j5OItQpo088032; Fri, 24 Jun 2005 11:55:26 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.3/8.13.1/Submit) id j5OItKYY088026; Fri, 24 Jun 2005 11:55:20 -0700 (PDT) (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: Fri, 24 Jun 2005 11:55:19 -0700 User-Agent: KMail/1.8 References: <200506131616.j5DGGDfr067534@lurza.secnetix.de> <20050624133457.GC65546@dragon.NUXI.org> <200506241548.17768.josemi@redesjm.local> In-Reply-To: <200506241548.17768.josemi@redesjm.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200506241155.20644.peter@wemm.org> Cc: Martin Cracauer Subject: Re: Athlon64 board with ECC 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: Fri, 24 Jun 2005 18:55:29 -0000 On Friday 24 June 2005 06:48 am, Jose M Rodriguez wrote: > El Viernes, 24 de Junio de 2005 15:34, David O'Brien escribi=F3: > > On Thu, Jun 23, 2005 at 06:18:56PM -0400, Martin Cracauer wrote: > > > And I suppose the BIOS needs to support it, too, > > > > Correct. > > > > > although it is not > > > clear to me how ECC exceptions are supposed to be routed anyway. > > > Clearly some chip not being CPU or RAM needs to have a say in the > > > exception delivery? Anybody understands how this works? > > > > Why?? The memory controller is on the same die as the CPU. The > > exception is handled w/in the CPU and it never goes out to any > > support chip. > > Are you sure the mem. controller in the CPU is not > configured/affected by GPIO bits in the southbridge? Absolutely sure. The bios support that is needed is that it needs to=20 test the SPD parameters on the dimms (like it does when sizing memory)=20 and turn on ECC mode in the memory controller. The effect of this is=20 that all existing memory is garbled because ECC encodes 64 bits of data=20 to spread it across 72 bits of memory. =20 If the bios has used a temporary scratch area during startup, then it=20 will have to start over once the ECC mode if toggled. However, most of=20 the bios startup code runs entirely from rom with registers only until=20 memory is configured so this is mostly irrelevant. ECC errors are signalled by doing a CRC-error flood on the HT bus if=20 memory serves correctly. Various logic in the HT bridges convert this=20 into the eqivalent of a PCI #SERR and/or NMI. Note that this happens=20 regardless of whether ECC is supported because that is how fatal PCI=20 errors are reported. Anyway, there only motherboard requirements for ECC are: 1) all 72 pins of the dimms need to be wired up. 2) the bios needs to turn on ECC mode in the memory controller. Thats it. Some motherboard makers neglect to include an ECC option because they=20 don't see the point of it it because there is a small speed penalty in=20 certain benchmarks. That's why ECC defaults often to 'off' in bios=20 settings on consumer motherboards. ECC requires that a single random=20 byte being written to memory turn into a read-merge-write of the 64 bit=20 group as a whole. The system chipset is NOT A FACTOR in this. If a motherboard doesn't=20 support ECC, it is purely motherboard manufacturer laziness and nothing=20 to do with the chipset. =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 Fri Jun 24 18:58:53 2005 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 2E29516A41C for ; Fri, 24 Jun 2005 18:58:53 +0000 (GMT) (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 0AD5F43D48 for ; Fri, 24 Jun 2005 18:58:53 +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 E28322A905 for ; Fri, 24 Jun 2005 11:58:52 -0700 (PDT) (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 8BC88E2B5 for ; Fri, 24 Jun 2005 11:58:52 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.3/8.13.1) with ESMTP id j5OIwon4088119; Fri, 24 Jun 2005 11:58:50 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.3/8.13.1/Submit) id j5OIwo6t088118; Fri, 24 Jun 2005 11:58:50 -0700 (PDT) (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: Fri, 24 Jun 2005 11:58:49 -0700 User-Agent: KMail/1.8 References: <200506131616.j5DGGDfr067534@lurza.secnetix.de> <20050624133457.GC65546@dragon.NUXI.org> <20050624100435.A88745@cons.org> In-Reply-To: <20050624100435.A88745@cons.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506241158.50267.peter@wemm.org> Cc: Martin Cracauer Subject: Re: Athlon64 board with ECC 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: Fri, 24 Jun 2005 18:58:53 -0000 On Friday 24 June 2005 07:04 am, Martin Cracauer wrote: > David O'Brien wrote on Fri, Jun 24, 2005 at 06:34:57AM -0700: > > On Thu, Jun 23, 2005 at 06:18:56PM -0400, Martin Cracauer wrote: > > > And I suppose the BIOS needs to support it, too, > > > > Correct. > > > > > although it is not > > > clear to me how ECC exceptions are supposed to be routed anyway. > > > Clearly some chip not being CPU or RAM needs to have a say in the > > > exception delivery? Anybody understands how this works? > > > > Why?? The memory controller is on the same die as the CPU. The > > exception is handled w/in the CPU and it never goes out to any > > support chip. > > Hm, so what does the BIOS do if it has the ECC options, exactly? It just enables the bit in the host memory controller and then has to zero all physical memory to initialize the ECC data. > Does it set defaults in the CPU itself? If so it should be possible > to inspect and mess with these settings after startup? Yes, you can read it using the pciconf(8) tool to read the memory controller settings. It is pci device 24 if memory serves correctly. I don't have the info handy. I believe it is the public 'bios/kernel writers guide' on AMD's site that documents the ECC bits. I know I saw it somewhere in their public docs. -- 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 Fri Jun 24 20:59:30 2005 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 5C6D016A41C for ; Fri, 24 Jun 2005 20:59:30 +0000 (GMT) (envelope-from amd64@cybernetwork.org) Received: from webserver.glupus.net (186.80-203-151.nextgentel.com [80.203.151.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id A619443D1D for ; Fri, 24 Jun 2005 20:59:28 +0000 (GMT) (envelope-from amd64@cybernetwork.org) Received: from webmail.glupus.net (stitch [10.0.1.2]) by webserver.glupus.net (8.13.1/8.13.1) with ESMTP id j5OKxXII049453 for ; Fri, 24 Jun 2005 22:59:33 +0200 (CEST) (envelope-from amd64@cybernetwork.org) Received: from 192.168.1.25 (SquirrelMail authenticated user glupus); by webmail.glupus.net with HTTP; Fri, 24 Jun 2005 22:59:29 +0200 (CEST) Message-ID: <1642.192.168.1.25.1119646769.squirrel@192.168.1.25> Date: Fri, 24 Jun 2005 22:59:29 +0200 (CEST) From: "SectorONE" To: freebsd-amd64@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Dell 6850 Dual Intel 64-bit Xeon MP and no SMP X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: amd64@cybernetwork.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2005 20:59:30 -0000 I need some help here. Ive been running FreeBSD for some years now and only i386 platform. This time Ive bought some new Dell PowerEdge servers and need the possibility to address more than 4GB of ram and use some 64-bit stuff. One of them is a Dell PowerEdge 6850 with dual Intel 64-bit Xeon MP prosessors. After installing FreeBSD/amd64 5.4-RELEASE, I cvsuped for stable and now got 5.4-RELEASE-p2. I then added SMP support in my kernel and compiled world, compiled kernel installed kernel and installed world.(and of course some mergemaster in between) When I reboot the machine the dmesg gives me the following disturbing info: --- quote on --- SMP: CPU 8 exceeds maximum CPU 7, ignoring SMP: CPU 14 exceeds maximum CPU 7, ignoring SMP: CPU 9 exceeds maximum CPU 7, ignoring SMP: CPU 15 exceeds maximum CPU 7, ignoring --- quote off --- What in the world is going on here? Ive only got 2 physical CPUs with HTT(or something). Is there something wrong with some CPU_ID? Im confused and need help. Right now there is no SMP working. Here is the complete dmesg: --- quote on --- monstrous# dmesg SMP: CPU 8 exceeds maximum CPU 7, ignoring SMP: CPU 14 exceeds maximum CPU 7, ignoring SMP: CPU 9 exceeds maximum CPU 7, ignoring SMP: CPU 15 exceeds maximum CPU 7, ignoring 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 5.4-RELEASE-p2 #2: Fri Jun 24 19:52:54 CEST 2005 sectorone@monstrous.pcom.no:/usr/obj/usr/src/sys/MONSTROUS Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) MP CPU 3.66GHz (3657.53-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x659d,MON,DS_CPL,EST,TM2,CNTX-ID,CX16,> AMD Features=0x20100800 Hyperthreading: 2 logical CPUs real memory = 5100273664 (4864 MB) avail memory = 4117934080 (3927 MB) ACPI APIC Table: ioapic1: Changing APIC ID to 1 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 2 ioapic2: WARNING: intbase 64 != expected base 56 ioapic3: Changing APIC ID to 3 ioapic3: WARNING: intbase 96 != expected base 88 ioapic4: Changing APIC ID to 4 ioapic4: WARNING: intbase 128 != expected base 120 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard ioapic3 irqs 96-119 on motherboard ioapic4 irqs 128-151 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 2.0 on pci0 pci4: on pcib2 pcib3: at device 3.0 on pci0 pci7: on pcib3 pcib4: at device 4.0 on pci0 pci8: on pcib4 pcib5: at device 5.0 on pci0 pci11: on pcib5 pcib6: at device 6.0 on pci0 pci14: on pcib6 pcib7: mem 0xdf6ff000-0xdf6fffff at device 0.0 on pci14 pci15: on pcib7 pcib8: at device 0.2 on pci14 pci18: on pcib8 bge0: mem 0xdf8f0000-0xdf8fffff irq 64 at device 2.0 on pci18 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:0f:1f:ff:ab:3c bge1: mem 0xdf8e0000-0xdf8effff irq 65 at device 2.1 on pci18 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:0f:1f:ff:ab:3d pcib9: at device 7.0 on pci0 pci19: on pcib9 pcib10: at device 0.0 on pci19 pci20: on pcib10 amr0: mem 0xdf4c0000-0xdf4fffff,0xdd0f0000-0xdd0fffff irq 110 at device 14.0 on pci20 amr0: Firmware 513W, BIOS H419, 256MB RAM pcib11: at device 0.2 on pci19 pci21: on pcib11 pci0: at device 9.0 (no driver attached) pci0: at device 9.1 (no driver attached) pci0: at device 9.2 (no driver attached) pci0: at device 9.3 (no driver attached) pci0: at device 9.4 (no driver attached) pci0: at device 9.5 (no driver attached) pci0: at device 9.6 (no driver attached) pci0: at device 9.7 (no driver attached) pci0: at device 11.0 (no driver attached) pci0: at device 11.1 (no driver attached) pci0: at device 11.2 (no driver attached) pci0: at device 11.3 (no driver attached) pci0: at device 11.4 (no driver attached) pci0: at device 11.5 (no driver attached) pci0: at device 11.6 (no driver attached) pci0: at device 11.7 (no driver attached) pci0: at device 13.0 (no driver attached) pci0: at device 13.1 (no driver attached) pci0: at device 13.2 (no driver attached) pci0: at device 13.3 (no driver attached) pci0: at device 13.4 (no driver attached) pci0: at device 13.5 (no driver attached) pci0: at device 13.6 (no driver attached) pci0: at device 13.7 (no driver attached) pci0: at device 15.0 (no driver attached) pci0: at device 15.1 (no driver attached) pci0: at device 15.2 (no driver attached) pci0: at device 15.3 (no driver attached) pci0: at device 15.4 (no driver attached) pci0: at device 15.5 (no driver attached) pci0: at device 15.6 (no driver attached) pci0: at device 15.7 (no driver attached) uhci0: port 0x6ce0-0x6cff irq 16 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x6cc0-0x6cdf irq 19 at device 29.1 on pci0 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 0x6ca0-0x6cbf irq 18 at device 29.2 on pci0 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 pci0: at device 29.7 (no driver attached) pcib12: at device 30.0 on pci0 pci22: on pcib12 pci22: at device 0.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A orm0: at iomem 0xec000-0xeffff,0xce800-0xcffff,0xcb000-0xcbfff,0xc0000-0xcafff on isa0 atkbdc0: at port 0x64,0x60 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 uhub3: Dell product 0xa001, class 9/0, rev 2.00/0.00, addr 2 uhub3: 2 ports with 2 removable, self powered Timecounter "TSC" frequency 3657528028 Hz quality 800 Timecounters tick every 1.000 msec IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to deny, logging limited to 100 packets/entry by default acd0: CDROM at ata0-master PIO4 amrd0: on amr0 amrd0: 139760MB (286228480 sectors) RAID 5 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device Mounting root from ufs:/dev/amrd0s1a Interrupt storm detected on "irq18: uhci2"; throttling interrupt source --- quote off --- My co-workers talk about substituting me and start running something called linux on it.. and I refuse.. Please help :) From owner-freebsd-amd64@FreeBSD.ORG Fri Jun 24 22:02:36 2005 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 2006C16A41C; Fri, 24 Jun 2005 22:02:36 +0000 (GMT) (envelope-from cjia@cse.unl.edu) Received: from cse-mail.unl.edu (cse-mail.unl.edu [129.93.165.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6FB643D49; Fri, 24 Jun 2005 22:02:35 +0000 (GMT) (envelope-from cjia@cse.unl.edu) Received: from [129.93.176.247] (pcp064958pcs.unl.edu [129.93.176.247]) (authenticated bits=0) by cse-mail.unl.edu (8.13.1/8.13.1) with ESMTP id j5OM2TCg012928 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 24 Jun 2005 17:02:30 -0500 (CDT) Message-ID: <42BC8310.9040501@cse.unl.edu> Date: Fri, 24 Jun 2005 17:02:56 -0500 From: Neo Jia User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-java@freebsd.org, freebsd-amd64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.49 on 129.93.165.11 Cc: Subject: How to build JDK15 on AMD64 with 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: Fri, 24 Jun 2005 22:02:36 -0000 All, These days, I tried to build the JDK15 on AMD64 with Fedora Core 3, but failed. And I happened to find out that in these two mailing lists, there were many people who had successfully built it with FreeBSD. I hope I could get some detailed information about the building procedure. Do you also use the source code from SUN SCSL or another version maintained by FreeBSD.org? What is the requirement I should meet to build it on FreeBSD, such as the version of FreeBSD? Do I still need GCC 3.2.2? Sorry about so many questions at the first time. Your instructions will be greatly appreciated! Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! From owner-freebsd-amd64@FreeBSD.ORG Sat Jun 25 00:16:46 2005 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 72B9116A41C for ; Sat, 25 Jun 2005 00:16:46 +0000 (GMT) (envelope-from noble.hays@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3885443D49 for ; Sat, 25 Jun 2005 00:16:46 +0000 (GMT) (envelope-from noble.hays@gmail.com) Received: by zproxy.gmail.com with SMTP id 13so6759nzn for ; Fri, 24 Jun 2005 17:16:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=uixUo9rNJnf1838aDsdDuO++GWcNqu2rgh1AQag43Agy0qEugtOkepn5iqfZdQN6B0L7Yx9ijD1wlW+iotj3eiT87x7cRmxzZD9Ab98uLug4jpWyxDnz2P9/TQ2UNt0OUTAlJf9I50dy6RI/6Uvw78phxYRzsW35v/4BRqk+k/Y= Received: by 10.36.66.5 with SMTP id o5mr2857551nza; Fri, 24 Jun 2005 17:16:45 -0700 (PDT) Received: from ?192.168.0.10? ([68.107.212.249]) by mx.gmail.com with ESMTP id 36sm3315701nzk.2005.06.24.17.16.44; Fri, 24 Jun 2005 17:16:45 -0700 (PDT) Message-ID: <42BCA269.9040303@gmail.com> Date: Fri, 24 Jun 2005 19:16:41 -0500 From: Noble Hays User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050621) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <42BC4681.80009@gmail.com> In-Reply-To: <42BC4681.80009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: AN8 motherboard SATA issues? 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, 25 Jun 2005 00:16:46 -0000 Noble Hays wrote: > Well, My father and I are attempteing to move to the 64 bit universe, > and so far, no good. > > We recived our purchase from new egg and now have a machine with the > following specs: > A-Bit AN8 Guru board > AMD 64 3000+ > NVidia GeForce 6600 PCI-E > 512 DDR 400 > 2x Segate SATA 150 80.0GB Harddrives > 1 120GB Segate Harddrive(not recived yet) > AOpen DVD+-RW DL > I downloaded the AMD64 disk1 iso off of FreeBSD's main site, burned it > succesfully of my old machine, and tried to install... the CD Loader > worked, then the Bootloader, then I selected the default at the > prompt, and it started detecting hardware... > > Here's the problem... It freezes up after detecting the SATA drives > and it moves through the detections quickly so I can't read any of the > warnings... when it freezes scroll lock doesn't allow me to look back > and see if everything else is working. I had a i386 5.4 disk, and > tried it just to make sure there wasn't a burn issue, it sticks at > exactly the same spot. > > I'm fairly new to freebsd, and me and dad are both new to the 64bit > systems. So this maybe an id-ten-t user problem, but if someone has > some suggestions, I'd like to try them. > > Thanks for your patience. > Well, I've learned a little more, we found the knoppix cd and ran memtest. We found some memory errors and now were trying to figure out if it's the memory or the board's memory controller. Sorry for the trouble. From owner-freebsd-amd64@FreeBSD.ORG Sat Jun 25 13:19:21 2005 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 85D6216A41C; Sat, 25 Jun 2005 13:19:21 +0000 (GMT) (envelope-from till@f111.hadiko.de) Received: from spamhost.rz.uni-karlsruhe.de (spamhost.rz.uni-karlsruhe.de [129.13.185.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 375F143D1F; Sat, 25 Jun 2005 13:19:21 +0000 (GMT) (envelope-from till@f111.hadiko.de) Received: from f111.hadiko.de (hadif111.hadiko.uni-karlsruhe.de [172.20.42.141]) by spamhost.rz.uni-karlsruhe.de with esmtp (Exim 4.43 #1) id 1DmAZ3-0001yc-04 ; Sat, 25 Jun 2005 15:19:19 +0200 Received: from lap.f111.hadiko.de ([10.0.0.220]) by f111.hadiko.de (8.12.9/8.12.9) with ESMTP id j5PDJFxq065489; Sat, 25 Jun 2005 13:19:16 GMT (envelope-from till@f111.hadiko.de) To: "Neo Jia" , freebsd-java@freebsd.org, freebsd-amd64@freebsd.org References: <42BC8310.9040501@cse.unl.edu> Message-ID: Date: Sat, 25 Jun 2005 15:19:14 +0200 From: "Till Riedel" Organization: Hadiko Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <42BC8310.9040501@cse.unl.edu> User-Agent: Opera M2/8.01 (FreeBSD, build 1204) X-Spam-Report: -3.3 ALL_TRUSTED Did not pass through any untrusted hosts 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.4382] -0.0 ALL_CAMPUS Received by smtp.rz from campus X-Spam-Status: no, hits=-3.3 required=5.0 X-Spam-Level: --- X-Scan-Server: spamhost X-Scan-Signature: 4b4e315e07894f13c13f341ff8335f3b Cc: Subject: Re: How to build JDK15 on AMD64 with 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: Sat, 25 Jun 2005 13:19:21 -0000 On Sat, 25 Jun 2005 00:02:56 +0200, Neo Jia wrote: I > hope I could get some detailed information about the building procedure. > Do you also use the source code from SUN SCSL or another version > maintained by FreeBSD.org? What is the requirement I should meet to > build it on FreeBSD, such as the version of FreeBSD? Do I still need GCC > 3.2.2? I build jdk-1.5.0p1_2 from the ports tree on a 5.4-RELEASE (gcc 3.4.2). At some point compilation failed because of too long command line. To work around I executed the failing command on the shell and restarted make. till From owner-freebsd-amd64@FreeBSD.ORG Sat Jun 25 21:23:27 2005 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 47A6616A41C; Sat, 25 Jun 2005 21:23:27 +0000 (GMT) (envelope-from cjia@cse.unl.edu) Received: from cse-mail.unl.edu (cse-mail.unl.edu [129.93.165.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F9D243D4C; Sat, 25 Jun 2005 21:23:26 +0000 (GMT) (envelope-from cjia@cse.unl.edu) Received: from [129.93.176.247] (pcp064958pcs.unl.edu [129.93.176.247]) (authenticated bits=0) by cse-mail.unl.edu (8.13.1/8.13.1) with ESMTP id j5PLNJIP010524 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 25 Jun 2005 16:23:20 -0500 (CDT) Message-ID: <42BDCB62.1030602@cse.unl.edu> Date: Sat, 25 Jun 2005 16:23:46 -0500 From: Neo Jia User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Till Riedel References: <42BC8310.9040501@cse.unl.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.49 on 129.93.165.11 Cc: freebsd-amd64@freebsd.org, freebsd-java@freebsd.org Subject: Re: How to build JDK15 on AMD64 with 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: Sat, 25 Jun 2005 21:23:27 -0000 Till, Thank you for your information. One question about your build, do you make any modification on the SUN JAVA SCSL? I am afraid that you cannot pass the sanity checking with the gcc 3.4.2? And the default GCC used by 5.4-RELEASE is 3.4.2, right? Thanks, Neo Till Riedel wrote: > On Sat, 25 Jun 2005 00:02:56 +0200, Neo Jia wrote: > I > >> hope I could get some detailed information about the building >> procedure. Do you also use the source code from SUN SCSL or another >> version maintained by FreeBSD.org? What is the requirement I should >> meet to build it on FreeBSD, such as the version of FreeBSD? Do I >> still need GCC 3.2.2? > > I build jdk-1.5.0p1_2 from the ports tree on a 5.4-RELEASE (gcc 3.4.2). > At some point compilation failed because of > too long command line. To work around I executed the failing command > on the shell and restarted make. > > till > _______________________________________________ > freebsd-java@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-java > To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org" -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using!