From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 01:59:41 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 D23BC16A41F for ; Sun, 4 Sep 2005 01:59:41 +0000 (GMT) (envelope-from neshort@yahoo.com) Received: from web30715.mail.mud.yahoo.com (web30715.mail.mud.yahoo.com [68.142.201.253]) by mx1.FreeBSD.org (Postfix) with SMTP id 5F81B43D45 for ; Sun, 4 Sep 2005 01:59:41 +0000 (GMT) (envelope-from neshort@yahoo.com) Received: (qmail 77321 invoked by uid 60001); 4 Sep 2005 01:59:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bDW2gvH0dJ3KxZQHyBq5YcAhoOUc2Wp40z9J+udLv3itNhwkLG+PZYqP0GB5TmsDXfXKvwVYhYpAk/RuJrAjdcF73Zn+iTvouo/7cywzbmiObp4TUEaZZLTkbUOfltaW4TxR1vB4knzXfTc927XJ0Y8WJMfNbG/6JkiiUqPZ9+k= ; Message-ID: <20050904015940.77319.qmail@web30715.mail.mud.yahoo.com> Received: from [216.198.97.37] by web30715.mail.mud.yahoo.com via HTTP; Sat, 03 Sep 2005 18:59:40 PDT Date: Sat, 3 Sep 2005 18:59:40 -0700 (PDT) From: Neil Short To: David Reid , freebsd-amd64@freebsd.org In-Reply-To: <4319F6D4.5090704@jetnet.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Mounting cd-rom 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, 04 Sep 2005 01:59:41 -0000 does it matter which cdrom? I.e., if you use a different disc, is the behavior the same? --- David Reid wrote: > When trying to mount a cd the system just reboots! > The only clue is this > line in /var/log/messages > > Sep 3 20:06:28 draak kernel: > g_vfs_done():acd0[READ(offset=32768, > length=2048)]error = 5 > > Anyone else seen this or is there something else I > can try to eliminate > this problem? System is running -CURRENT from about > a week ago. > > Thanks > > david > _______________________________________________ > 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" > If history always begins this morning, the world holds exciting surprises around every corner (241). --Ann Coulter. Treason. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 03:20: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 16BAD16A41F for ; Sun, 4 Sep 2005 03:20:05 +0000 (GMT) (envelope-from Peter_Losher@isc.org) Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6E7343D48 for ; Sun, 4 Sep 2005 03:20:04 +0000 (GMT) (envelope-from Peter_Losher@isc.org) Received: from [10.0.0.3] (c-24-4-233-31.hsd1.ca.comcast.net [24.4.233.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 63597677F6 for ; Sun, 4 Sep 2005 03:20:04 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Message-ID: <431A67DE.6020606@isc.org> Date: Sat, 03 Sep 2005 20:19:58 -0700 From: Peter Losher Organization: ISC User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org X-Enigmail-Version: 0.91.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2DC330ABB5DFC5A6C9B81814" Subject: Is there a HOWTO to get linuxpluginwrapper to work under 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: Sun, 04 Sep 2005 03:20:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2DC330ABB5DFC5A6C9B81814 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit in particular, how to get the flashplugin to work under linux i386 emulation. whenever I go to get the linux dependencies, they go for the amd64 packages, not the i386 ones. Has anyone gotten it to work, and if so, can they list the process (or point to a web page that does)? ;) Best Wishes - Peter -- Peter_Losher@isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow" --------------enig2DC330ABB5DFC5A6C9B81814 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iD8DBQFDGmfjPtVx9OgEjQgRAr+PAJ9lxsId7NSpPV93lvvUfMKvD2y8WQCfYb8Y UPzCBjcyOX8fHlFsDITTfDY= =Prvg -----END PGP SIGNATURE----- --------------enig2DC330ABB5DFC5A6C9B81814-- From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 08:01:19 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 6C28A16A41F for ; Sun, 4 Sep 2005 08:01:19 +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 C5A3843D45 for ; Sun, 4 Sep 2005 08:01:18 +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 j8480nV8021079; Sun, 4 Sep 2005 01:00: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 j8480jKd021077; Sun, 4 Sep 2005 01:00:45 -0700 (PDT) (envelope-from obrien) Date: Sun, 4 Sep 2005 01:00:45 -0700 From: "David O'Brien" To: Tomaz Borstnar Message-ID: <20050904080045.GA20880@dragon.NUXI.org> References: <431842CA.4030008@mail.uni-mainz.de> <20050902150653.GA78096@misty.eyesbeyond.com> <6.2.3.4.0.20050903213157.047f8560@193.189.169.9> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.3.4.0.20050903213157.047f8560@193.189.169.9> X-Operating-System: FreeBSD 7.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: Stable and working JAVA for pure 64 Bit environment? 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, 04 Sep 2005 08:01:19 -0000 On Sat, Sep 03, 2005 at 09:32:35PM +0200, Tomaz Borstnar wrote: > At 17:06 2.9.2005, Greg Lewis wrote: > >On Fri, Sep 02, 2005 at 02:17:14PM +0200, O. Hartmann wrote: > >> Hello out here. > >> I run an Athlon64 based FreeBSD 6.0 box and this machine is for several > >> purposes a pure 64 Bit box. My intention now is to find a working JAVA > >> environment for a pure 64Bit environment on FBSD 6.0. Any suggestions? > > > >The java/jdk15 port. > > Just dont try to build it on 5.x :) It wont work. 6beta can build it just > fine. It would be great if a FreeBSD 5.x user could diff 5.x with 6.0 and find the change that fixed this. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 08:04: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 CEDC616A41F for ; Sun, 4 Sep 2005 08:04:56 +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 EE6B443D55 for ; Sun, 4 Sep 2005 08:04:54 +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 j8484oHw021159; Sun, 4 Sep 2005 01:04:50 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j8484asc021154; Sun, 4 Sep 2005 01:04:36 -0700 (PDT) (envelope-from obrien) Date: Sun, 4 Sep 2005 01:04:36 -0700 From: "David O'Brien" To: Ken Gunderson Message-ID: <20050904080436.GC20880@dragon.NUXI.org> References: <122ec19705090206416fd81365@mail.gmail.com> <20050902094726.36bb1340.kgunders@teamcool.net> <4318C217.4000604@jetnet.co.uk> <20050902160419.0b079288.kgunders@teamcool.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050902160419.0b079288.kgunders@teamcool.net> X-Operating-System: FreeBSD 7.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: Asus A8N Deluxe sli (for anyone thats using one) 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, 04 Sep 2005 08:04:57 -0000 On Fri, Sep 02, 2005 at 04:04:19PM -0600, Ken Gunderson wrote: > > I would run away from any such board :-( > > That was my initial preference but when I started shoping realized how > far behind the VIA based stuff is I had to rethink this. Why is VIA based boards "so far behind"? SLI isn't supported on Linux nor FreeBSD, so that cannot be the reason. Early K8T890 boards won't support Athlon64 X2 dual-core CPU's, but the latest revision does. So what is so behind? -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 08:09: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 B175F16A41F for ; Sun, 4 Sep 2005 08:09:34 +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 05F3143D45 for ; Sun, 4 Sep 2005 08:09:31 +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 j8489TG0021202; Sun, 4 Sep 2005 01:09:30 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j8489TcR021201; Sun, 4 Sep 2005 01:09:29 -0700 (PDT) (envelope-from obrien) Date: Sun, 4 Sep 2005 01:09:29 -0700 From: "David O'Brien" To: Ken Gunderson Message-ID: <20050904080928.GD20880@dragon.NUXI.org> References: <20050816121701.74816.qmail@web54306.mail.yahoo.com> <4301E39F.1050500@samsco.org> <20050816204229.758827a5.kgunders@teamcool.net> <4302AA97.8030002@samsco.org> <20050816235300.4dc8924e.kgunders@teamcool.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050816235300.4dc8924e.kgunders@teamcool.net> X-Operating-System: FreeBSD 7.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: Asus A8V-E Deluxe discontinued (was Re: Hi) 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, 04 Sep 2005 08:09:34 -0000 On Tue, Aug 16, 2005 at 11:53:00PM -0600, Ken Gunderson wrote: > On Tue, 16 Aug 2005 21:10:15 -0600 Scott Long wrote: > > > I just noticed that Asus is discontinuing this mainboard so if you've > > > been wanting one it's a good time to get one while you can. Might look > > > for them to be priced for clearance as well... > > > > I forgot to mention that this board doesn't support dual core chips. > > That's probably why it's being discontinued. > > Which seems a bit incongruous at first blush since per Asus website the > A8V-E SE does support dual core and both boards use the same VIA K8T890 > chipset but I guess there's some other stumbling block. The first revision of the K8T890 has bug that prevents the use of dual-core CPU's. The A8V-E SE (second edition) uses the newer silicon revision. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 08:10:33 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 AAB8B16A41F for ; Sun, 4 Sep 2005 08:10:33 +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 EAA0743D48 for ; Sun, 4 Sep 2005 08:10: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 j848AUl8021222; Sun, 4 Sep 2005 01:10:30 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j848AT60021221; Sun, 4 Sep 2005 01:10:29 -0700 (PDT) (envelope-from obrien) Date: Sun, 4 Sep 2005 01:10:29 -0700 From: "David O'Brien" To: Skreetch Message-ID: <20050904081029.GE20880@dragon.NUXI.org> References: <43023088.90500@yahoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43023088.90500@yahoo.fr> X-Operating-System: FreeBSD 7.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: Openoffice 1.1 with gcc-ooo 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, 04 Sep 2005 08:10:33 -0000 On Tue, Aug 16, 2005 at 08:29:28PM +0200, Skreetch wrote: > I'd like to install OpenOffice 1.1 using the ports collection OpenOffice isn't 64-bit clean, and one one has figured out how to co-install 32-bit and 64-bit ports. So even if gcc-ooo would build, you woundn't get anywhere. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 08:17: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 4920F16A41F for ; Sun, 4 Sep 2005 08:17:44 +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 83E8843D48 for ; Sun, 4 Sep 2005 08:17:43 +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 j848Hdd9021349; Sun, 4 Sep 2005 01:17:40 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j848HbVU021346; Sun, 4 Sep 2005 01:17:37 -0700 (PDT) (envelope-from obrien) Date: Sun, 4 Sep 2005 01:17:36 -0700 From: "David O'Brien" To: Pedro A M Vazquez Message-ID: <20050904081736.GF20880@dragon.NUXI.org> References: <200508250852.j7P8q0a5002727@peedub.jennejohn.org> <20050825111043.B14600@penelope.iqm.unicamp.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050825111043.B14600@penelope.iqm.unicamp.br> X-Operating-System: FreeBSD 7.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: AMD Core Math Library 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, 04 Sep 2005 08:17:44 -0000 On Thu, Aug 25, 2005 at 11:10:43AM -0300, Pedro A M Vazquez wrote: > Is there any chance we could convince AMD to build the AMD Core Math > Libs for FreeBSD AMD64 (and 32bits too) ? They have a gcc/g77 compiled > version for Linux, it would be just a matter of build it on FBSD. Just use the "Linux" version. I've tested it on FreeBSD and it works fine. It is an ELF object w/o system calls. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 08:37: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 906DF16A41F for ; Sun, 4 Sep 2005 08:37:11 +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 DED2043D45 for ; Sun, 4 Sep 2005 08:37:10 +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 j848ar8o021699; Sun, 4 Sep 2005 01:36:54 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j848aqWs021698; Sun, 4 Sep 2005 01:36:52 -0700 (PDT) (envelope-from obrien) Date: Sun, 4 Sep 2005 01:36:52 -0700 From: "David O'Brien" To: Martin Cracauer Message-ID: <20050904083652.GI20880@dragon.NUXI.org> References: <20050815125657.A92343@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050815125657.A92343@cons.org> X-Operating-System: FreeBSD 7.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: 4 GB RAM showing up as 3, BIOS memory hole and all that 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, 04 Sep 2005 08:37:11 -0000 On Mon, Aug 15, 2005 at 12:56:57PM -0400, Martin Cracauer wrote: > I have a Dual Opteron board with 4x 1 GB RAM. The memory count in the > BIOS goes up to 640 KB + 3072 MB, and FreeBSD says it sees 3 GB. > > I know/assume/heared this has to do with the I/O space placed in the > upper GB and that you can re-map the top GB to avoid the problem. ... > Any way to get my GB back? Depends on the BIOS. Some BIOS's have knobs for the "memory hole" and simply control how large the hole is. Others have nobs for the "memory hole" that AMD internal often calls the better named "memory hoisting" - which is what you are asking for. Revision E CPU's have better HW support for memory hoisting, but some BIOS's control of it are still buggy. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 10:55:55 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 B582D16A41F for ; Sun, 4 Sep 2005 10:55:55 +0000 (GMT) (envelope-from pav@oook.cz) Received: from hood.oook.cz (hood.oook.cz [212.27.205.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AF3243D48 for ; Sun, 4 Sep 2005 10:55:54 +0000 (GMT) (envelope-from pav@oook.cz) Received: from ikaros.oook.cz (localhost [127.0.0.1]) by hood.oook.cz (8.13.4/8.13.4) with ESMTP id j84AtrQi096555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Sep 2005 12:55:53 +0200 (CEST) (envelope-from pav@oook.cz) Received: (from pav@localhost) by ikaros.oook.cz (8.13.4/8.13.4/Submit) id j84AtqG1096548; Sun, 4 Sep 2005 12:55:52 +0200 (CEST) (envelope-from pav@oook.cz) X-Authentication-Warning: ikaros.oook.cz: pav set sender to pav@oook.cz using -f From: Pav Lucistnik To: Peter Losher In-Reply-To: <431A67DE.6020606@isc.org> References: <431A67DE.6020606@isc.org> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Date: Sun, 04 Sep 2005 12:55:52 +0200 Message-Id: <1125831352.52976.4.camel@ikaros.oook.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-amd64@freebsd.org Subject: Re: Is there a HOWTO to get linuxpluginwrapper to work under 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: Sun, 04 Sep 2005 10:55:55 -0000 Peter Losher p=ED=B9e v so 03. 09. 2005 v 20:19 -0700: > in particular, how to get the flashplugin to work under linux i386 > emulation. whenever I go to get the linux dependencies, they go for the > amd64 packages, not the i386 ones. Has anyone gotten it to work, and if > so, can they list the process (or point to a web page that does)? ;) You can't get linuxpluginwrapper to work under amd64 - there's no support for it. Yet. --=20 Pav Lucistnik salek tekutiny temer uplne ale ne zcela naprosto nepodobne caji From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 12:47:26 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 7097516A41F for ; Sun, 4 Sep 2005 12:47:26 +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 DA8E543D45 for ; Sun, 4 Sep 2005 12:47:25 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id j84ClOui024372; Sun, 4 Sep 2005 14:47:24 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.3/8.12.9/Submit) id j84ClOfB024371; Sun, 4 Sep 2005 08:47:24 -0400 (EDT) (envelope-from cracauer) Date: Sun, 4 Sep 2005 08:47:24 -0400 From: Martin Cracauer To: freebsd-amd64@freebsd.org Message-ID: <20050904084724.A24355@cons.org> References: <20050815125657.A92343@cons.org> <20050904083652.GI20880@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: <20050904083652.GI20880@dragon.NUXI.org>; from obrien@freebsd.org on Sun, Sep 04, 2005 at 01:36:52AM -0700 Cc: Martin Cracauer Subject: Re: 4 GB RAM showing up as 3, BIOS memory hole and all that 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, 04 Sep 2005 12:47:26 -0000 David O'Brien wrote on Sun, Sep 04, 2005 at 01:36:52AM -0700: > On Mon, Aug 15, 2005 at 12:56:57PM -0400, Martin Cracauer wrote: > > I have a Dual Opteron board with 4x 1 GB RAM. The memory count in the > > BIOS goes up to 640 KB + 3072 MB, and FreeBSD says it sees 3 GB. > > > > I know/assume/heared this has to do with the I/O space placed in the > > upper GB and that you can re-map the top GB to avoid the problem. > ... > > Any way to get my GB back? > > Depends on the BIOS. Some BIOS's have knobs for the "memory hole" and > simply control how large the hole is. Others have nobs for the "memory > hole" that AMD internal often calls the better named "memory hoisting" - > which is what you are asking for. Revision E CPU's have better HW support > for memory hoisting, but some BIOS's control of it are still buggy. Thanks, David. A BIOS update did indeed give me my top gigabyte back, sans 128 MB for my video card. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 13:56:19 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 6F68116A41F for ; Sun, 4 Sep 2005 13:56:19 +0000 (GMT) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (glewis.dsl.xmission.com [166.70.56.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id D19F543D45 for ; Sun, 4 Sep 2005 13:56:18 +0000 (GMT) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.13.3/8.13.3) with ESMTP id j84DuGGI022592; Sun, 4 Sep 2005 07:56:17 -0600 (MDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.13.3/8.13.3/Submit) id j84DuFV2022591; Sun, 4 Sep 2005 07:56:15 -0600 (MDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Sun, 4 Sep 2005 07:56:15 -0600 From: Greg Lewis To: freebsd-amd64@FreeBSD.org Message-ID: <20050904135615.GC22476@misty.eyesbeyond.com> References: <431842CA.4030008@mail.uni-mainz.de> <20050902150653.GA78096@misty.eyesbeyond.com> <6.2.3.4.0.20050903213157.047f8560@193.189.169.9> <20050904080045.GA20880@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050904080045.GA20880@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i Cc: "O. Hartmann" Subject: Re: Stable and working JAVA for pure 64 Bit environment? 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, 04 Sep 2005 13:56:19 -0000 On Sun, Sep 04, 2005 at 01:00:45AM -0700, David O'Brien wrote: > On Sat, Sep 03, 2005 at 09:32:35PM +0200, Tomaz Borstnar wrote: > > At 17:06 2.9.2005, Greg Lewis wrote: > > >On Fri, Sep 02, 2005 at 02:17:14PM +0200, O. Hartmann wrote: > > >> Hello out here. > > >> I run an Athlon64 based FreeBSD 6.0 box and this machine is for several > > >> purposes a pure 64 Bit box. My intention now is to find a working JAVA > > >> environment for a pure 64Bit environment on FBSD 6.0. Any suggestions? > > > > > >The java/jdk15 port. > > > > Just dont try to build it on 5.x :) It wont work. 6beta can build it just > > fine. > > It would be great if a FreeBSD 5.x user could diff 5.x with 6.0 and find > the change that fixed this. I believe its somewhere in the Linux emulation code, fwiw. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 16:04: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 6415416A421 for ; Sun, 4 Sep 2005 16:04:53 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7255143D6E for ; Sun, 4 Sep 2005 16:04:47 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 95BD211EE4 for ; Sun, 4 Sep 2005 10:04:42 -0600 (MDT) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 5CB9D11EE3 for ; Sun, 4 Sep 2005 10:04:42 -0600 (MDT) Date: Sun, 4 Sep 2005 10:04:41 -0600 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20050904100441.1f7ed7fc.kgunders@teamcool.net> In-Reply-To: <20050904080436.GC20880@dragon.NUXI.org> References: <122ec19705090206416fd81365@mail.gmail.com> <20050902094726.36bb1340.kgunders@teamcool.net> <4318C217.4000604@jetnet.co.uk> <20050902160419.0b079288.kgunders@teamcool.net> <20050904080436.GC20880@dragon.NUXI.org> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Asus A8N Deluxe sli (for anyone thats using one) 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, 04 Sep 2005 16:04:53 -0000 On Sun, 4 Sep 2005 01:04:36 -0700 "David O'Brien" wrote: > On Fri, Sep 02, 2005 at 04:04:19PM -0600, Ken Gunderson wrote: > > > I would run away from any such board :-( > > > > That was my initial preference but when I started shoping realized how > > far behind the VIA based stuff is I had to rethink this. > > Why is VIA based boards "so far behind"? SLI isn't supported on Linux > nor FreeBSD, so that cannot be the reason. Early K8T890 boards won't > support Athlon64 X2 dual-core CPU's, but the latest revision does. So > what is so behind? Well now that your other post has illuminated the K8T890 first/second revision dual core support difference searching mainboard manufacture's sites becomes less confusing- the ones w/K8T890 boards that don't support dual core are apparently using older generation chips.... I'd like to have my board support 4 SATA connectors and I'd also like to have SATAII w/o having to go to auxillary RAID card. It's not critical but since my new drives are SATAII I'd like the board to support them. I've not found a K8T890 that does either of these whereas it's commonplace in nForce4 boards (I don't want/need SLI so have been taking a look at the Ultra stuff). One very frustrating thing was that recently the VIA based socket 939 portion of Asus's website was broken for a good two weeks and made it impossible to get "specifications". Prior to that it gave erroneous specs (and is still fubarred in various places...). Added to that an Asus distrib I know reports that Asus will not be using VIA chipsets in the future. So taken cummulatively this kind of just seemed to add up to VIA not being long for this world and perhaps not a prudent investment for a new board that one wants to be supported for the next few years.... All other things being equal I would love to NOT add a dime to nVidia's coffers. Unfortunately all things do not appear to be equal. I don't follow this at the level of detail others do, however, and am first to admit that I could be wrong...... -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 23:29:18 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 BF13416A41F for ; Sun, 4 Sep 2005 23:29:18 +0000 (GMT) (envelope-from fernando@schapachnik.com.ar) Received: from servidor1.cursosvirtuales.com.ar (www.cursosvirtuales.com.ar [200.59.46.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEFE443D45 for ; Sun, 4 Sep 2005 23:29:16 +0000 (GMT) (envelope-from fernando@schapachnik.com.ar) Received: from servidor1.cursosvirtuales.com.ar (localhost [127.0.0.1]) by servidor1.cursosvirtuales.com.ar (8.12.11/8.12.11) with ESMTP id j84NT3OE047611; Sun, 4 Sep 2005 20:29:04 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: from schapachnik.com.ar (uucp@localhost) by servidor1.cursosvirtuales.com.ar (8.12.11/8.12.11/Submit) with UUCP id j84NT3B2047608; Sun, 4 Sep 2005 20:29:03 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: from funes2.schapachnik.com.ar (localhost.schapachnik.com.ar [127.0.0.1]) by funes2.schapachnik.com.ar (8.13.4/8.13.4) with ESMTP id j84NSKPf000691; Sun, 4 Sep 2005 20:28:22 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: (from fpscha@localhost) by funes2.schapachnik.com.ar (8.13.4/8.13.4/Submit) id j84NSJqn000690; Sun, 4 Sep 2005 20:28:19 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) X-Authentication-Warning: funes2.schapachnik.com.ar: fpscha set sender to fernando@schapachnik.com.ar using -f Date: Sun, 4 Sep 2005 20:28:19 -0300 From: Fernando Schapachnik To: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= Message-ID: <20050904232819.GA672@funes2.schapachnik.com.ar> References: <200509012030.j81KUMrV080185@freefall.freebsd.org> <43176B44.2010600@cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <43176B44.2010600@cs.tu-berlin.de> User-Agent: Mutt/1.4.2.1i X-OS: FreeBSD 4.10 - http://www.freebsd.org Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/85451: 6.0-BETA3 lockups 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: Sun, 04 Sep 2005 23:29:18 -0000 En un mensaje anterior, Björn König escribió: > Fernando Schapachnik wrote: > >[...] > > > > > Further testing: network activity locks up the machine, even > > the > output of a buildworld, or a few seconds of ping -f. > > > > > > Without network activity, the machine is able to even > > buildworld. > > > > More: disabling PREEMPTION on the kernel config "solves" the > > problem. > > You told that the problems are related to network activity. Have > you tried debug.mpsafenet="0" in /boot/loader.conf too? This > might protect you from deadlocks, but may decrease performace. Just tried, and it still locks up. Fernando P. Schapachnik fernando@schapachnik.com.ar From owner-freebsd-amd64@FreeBSD.ORG Sun Sep 4 23:30: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 3D26F16A41F for ; Sun, 4 Sep 2005 23:30:47 +0000 (GMT) (envelope-from fernando@schapachnik.com.ar) Received: from servidor1.cursosvirtuales.com.ar (www.cursosvirtuales.com.ar [200.59.46.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6749243D48 for ; Sun, 4 Sep 2005 23:30:45 +0000 (GMT) (envelope-from fernando@schapachnik.com.ar) Received: from servidor1.cursosvirtuales.com.ar (localhost [127.0.0.1]) by servidor1.cursosvirtuales.com.ar (8.12.11/8.12.11) with ESMTP id j84NUMAp047929; Sun, 4 Sep 2005 20:30:23 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: from schapachnik.com.ar (uucp@localhost) by servidor1.cursosvirtuales.com.ar (8.12.11/8.12.11/Submit) with UUCP id j84NUMLL047928; Sun, 4 Sep 2005 20:30:22 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: from funes2.schapachnik.com.ar (localhost.schapachnik.com.ar [127.0.0.1]) by funes2.schapachnik.com.ar (8.13.4/8.13.4) with ESMTP id j84NUEdF000744; Sun, 4 Sep 2005 20:30:14 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: (from fpscha@localhost) by funes2.schapachnik.com.ar (8.13.4/8.13.4/Submit) id j84NUD58000743; Sun, 4 Sep 2005 20:30:13 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) X-Authentication-Warning: funes2.schapachnik.com.ar: fpscha set sender to fernando@schapachnik.com.ar using -f Date: Sun, 4 Sep 2005 20:30:13 -0300 From: Fernando Schapachnik To: Greg Lewis Message-ID: <20050904233013.GC672@funes2.schapachnik.com.ar> References: <431842CA.4030008@mail.uni-mainz.de> <20050902150653.GA78096@misty.eyesbeyond.com> <6.2.3.4.0.20050903213157.047f8560@193.189.169.9> <20050903211134.GA1573@misty.eyesbeyond.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050903211134.GA1573@misty.eyesbeyond.com> User-Agent: Mutt/1.4.2.1i X-OS: FreeBSD 4.10 - http://www.freebsd.org Cc: "O. Hartmann" , freebsd-amd64@freebsd.org Subject: Re: Stable and working JAVA for pure 64 Bit environment? 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, 04 Sep 2005 23:30:47 -0000 En un mensaje anterior, Greg Lewis escribió: > > >The java/jdk15 port. > > > > Just dont try to build it on 5.x :) It wont work. 6beta can build it just > > fine. Any idea where glibc-common-2.3.2-4.80.8.amd64.rpm and company can be found? Fernando P. Schapachnik fernando@schapachnik.com.ar From owner-freebsd-amd64@FreeBSD.ORG Mon Sep 5 06:41: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 B6C6516A41F for ; Mon, 5 Sep 2005 06:41:46 +0000 (GMT) (envelope-from ganael.laplanche@martymac.com) Received: from mail.martymac.com (martymac.com [82.224.94.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5809543D46 for ; Mon, 5 Sep 2005 06:41:46 +0000 (GMT) (envelope-from ganael.laplanche@martymac.com) Received: from martymac.com (localhost [127.0.0.1]) by mail.martymac.com (Postfix) with ESMTP id A62DB229; Mon, 5 Sep 2005 08:46:05 +0200 (CEST) From: "Ganael Laplanche" To: kometen@gmail.com, Otis Driftwood Date: Mon, 5 Sep 2005 06:46:05 +0000 Message-Id: <20050905064321.M60390@martymac.com> In-Reply-To: References: <43189F52.6010403@imperial.ac.uk> X-Mailer: Open WebMail 2.51 20050228 X-OriginatingIP: 81.57.27.189 (martymac) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Cc: freebsd-amd64@freebsd.org Subject: Re: e17 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, 05 Sep 2005 06:41:46 -0000 Hi, I've written a small script to compile e17 on FreeBSD and GNU/Linux. It is available here : http://contribs.martymac.com/e17/make_e17 You can give a try, It works for me :) Ganaël LAPLANCHE ganael.laplanche@martymac.com http://www.martymac.com Tel : (+33)6.84.03.57.24. ---------- Original Message ----------- From: Claus Guttesen To: Otis Driftwood Cc: freebsd-amd64@freebsd.org Sent: Sat, 3 Sep 2005 21:57:07 +0200 Subject: Re: e17 > > has anyone by any chance got e17 cvs working? > > I did a 'portinstall enlightenment-devel' and it installed right away. > > regards > Claus > _______________________________________________ > 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" ------- End of Original Message ------- From owner-freebsd-amd64@FreeBSD.ORG Mon Sep 5 11:02: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 24AD016A41F for ; Mon, 5 Sep 2005 11:02:02 +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 D92F343D48 for ; Mon, 5 Sep 2005 11:02:01 +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 j85B21Nm076820 for ; Mon, 5 Sep 2005 11:02:01 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j85B20x9076806 for freebsd-amd64@freebsd.org; Mon, 5 Sep 2005 11:02:00 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 5 Sep 2005 11:02:00 GMT Message-Id: <200509051102.j85B20x9076806@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, 05 Sep 2005 11:02:02 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/10/27] amd64/73211 amd64 FAST_IPSEC broken on amd64 o [2005/08/09] amd64/84693 amd64 Keyboard not recognized during first step 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/11/26] amd64/59714 amd64 device timeout and ad0: WARNING - WRITE_D o [2004/07/28] amd64/69704 amd64 ext2/ext3 unstable in amd64 o [2004/07/28] amd64/69707 amd64 IPC32 dont work OK in amd64 FreeBSD o [2004/09/07] amd64/71471 amd64 Can not install 5.3beta3/amd64 on IBM eSe o [2004/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. 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 o [2005/06/19] amd64/82425 amd64 fxp0: device timeout, fxp interface dies o [2005/06/23] amd64/82555 amd64 Kernel Panic - after i connect to my "amd o [2005/07/05] amd64/83005 amd64 Memory Occupied during installation of th o [2005/07/25] amd64/84027 amd64 if_nve gets stuck o [2005/08/12] amd64/84832 amd64 Installation crashes just at boot AMD64/ o [2005/08/14] amd64/84930 amd64 [msdosfs] something wrong with msdosfs on o [2005/08/18] amd64/85081 amd64 TeamSpeak o [2005/08/29] amd64/85431 amd64 AMD64 has short but temporary freezes (ha o [2005/08/29] amd64/85451 amd64 6.0-BETA3 lockups on AMD64 39 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 coredumps with either runs 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 o [2005/07/20] amd64/83806 amd64 Can not comple /usr/src/lib/msun/amd64/fe o [2005/08/07] amd64/84652 amd64 kbdmap -r dumps core o [2005/09/02] amd64/85626 amd64 java/jdk15 compile error 16 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon Sep 5 12:05:07 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 8C58F16A431 for ; Mon, 5 Sep 2005 12:05:07 +0000 (GMT) (envelope-from rsh.lists@comcast.net) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50EC843D46 for ; Mon, 5 Sep 2005 12:05:07 +0000 (GMT) (envelope-from rsh.lists@comcast.net) Received: from [192.168.1.11] (tardiss.hsd1.ma.comcast.net[66.30.82.93]) by comcast.net (rwcrmhc11) with ESMTP id <2005090512045501300b0679e>; Mon, 5 Sep 2005 12:05:06 +0000 Message-ID: <431C3461.1090108@comcast.net> Date: Mon, 05 Sep 2005 08:04:49 -0400 From: Sean User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050828) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ganael Laplanche References: <43189F52.6010403@imperial.ac.uk> <20050905064321.M60390@martymac.com> In-Reply-To: <20050905064321.M60390@martymac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Otis Driftwood , freebsd-amd64@freebsd.org Subject: Re: e17 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rsh.lists@comcast.net List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2005 12:05:08 -0000 Ganael Laplanche wrote: > Hi, > > I've written a small script to compile e17 on FreeBSD and GNU/Linux. It is > available here : http://contribs.martymac.com/e17/make_e17 > > You can give a try, It works for me :) > > ---------- Original Message ----------- > >>>has anyone by any chance got e17 cvs working? >> >>I did a 'portinstall enlightenment-devel' and it installed right away. >> >>regards >>Claus Seeing these messages I decided to give it a try as well. Like mentioned, the port installs without a problem. As expected being so early in its life a lot of functionality is not present but it looks real nice so far, and an interested when they get further into development. From owner-freebsd-amd64@FreeBSD.ORG Mon Sep 5 23:55:58 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 7C1D616A41F for ; Mon, 5 Sep 2005 23:55:58 +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 F195643D45 for ; Mon, 5 Sep 2005 23:55:57 +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 j85NttiY013552; Mon, 5 Sep 2005 16:55:55 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j85NtsUq013551; Mon, 5 Sep 2005 16:55:54 -0700 (PDT) (envelope-from obrien) Date: Mon, 5 Sep 2005 16:55:54 -0700 From: "David O'Brien" To: shellreef+freebsd@gmail.com Message-ID: <20050905235554.GA93379@dragon.NUXI.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 7.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: tomstdenis@gmail.com, freebsd-amd64@freebsd.org Subject: Re: [PATCH] LibTomCrypt on amd64 and -fPIC 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: Mon, 05 Sep 2005 23:55:58 -0000 On Wed, Aug 24, 2005 at 07:18:18PM -0700, shellreef@gmail.com wrote: > To FreeBSD-amd64: Can we add -fPIC to make.conf? Are there any > side-effects? (I'd prefer this as I use packages and would prefer to > not compile from ports.) No. -fPIC should only be used to build shared libraries. Not every since piece of code compiled for AMD64. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 00:00:38 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 1B8F416A420 for ; Tue, 6 Sep 2005 00:00:38 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0B9F43D62 for ; Tue, 6 Sep 2005 00:00:18 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j8600Ivf001015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Sep 2005 20:00:18 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j8600H6P017287; Mon, 5 Sep 2005 20:00:17 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 31620512E0; Mon, 5 Sep 2005 20:00:17 -0400 (EDT) Date: Mon, 5 Sep 2005 20:00:16 -0400 From: Kris Kennaway To: Claus Guttesen Message-ID: <20050906000016.GA91835@xor.obsecurity.org> References: <4316A5BC.1000405@meijome.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: Which SCHED_ for DB server X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2005 00:00:38 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 01, 2005 at 10:53:39AM +0200, Claus Guttesen wrote: > > I'm building a server that will run PostgreSQL with a database > > containing several 10s of million records. The only things happening on > > this box will be the SQL processes and other processes to parse raw data > > and load into the DB. Users =3D a few connections via HTTP from an > > intranet server (not more than 5 concurrently). > >=20 > > I was wondering what is the best SCHED_ to set in the kernel. > > I currently have SCHED_4BSD but was wondering if _ULE would be better > > for this >=20 > For prod. use I would recommend SCHED_4BSD atm. The 4BSD-scheduler > does seem to be more stable on SMP and up. ULE might be OK on SMP with 6.0 and above, but performance seems to be a bit lower than 4BSD in my tests. Try it yourself and see which is better. Kris --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDHNwQWry0BWjoQKURAkXpAKC2r4WkjyPr3JWoQKa8e7Wdek6DMwCfR1m4 PMhEHTvSd2s48Oj9Ry1jRXw= =UY1L -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 00:01: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 704C716A41F for ; Tue, 6 Sep 2005 00:01:24 +0000 (GMT) (envelope-from tomstdenis@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04D7943D4C for ; Tue, 6 Sep 2005 00:01:23 +0000 (GMT) (envelope-from tomstdenis@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so997071rng for ; Mon, 05 Sep 2005 17:01:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=l8Nue3uHYsl/z1UiSC5Tc0M+i8+sMZDvy8pliCPGsDL5uMrnfeR7skgXuf0W4pDKRgj84KAfIJ+n7ZbrFwFo8VW26rSyKW76O/p6XqEcHZHe7HgGVNixTAHmaQ/Hqozu+M0NM8comkzaFs60VKhJ/Vl8COLhknJuUNCuBGDbJvw= Received: by 10.11.88.37 with SMTP id l37mr41858cwb; Mon, 05 Sep 2005 17:01:23 -0700 (PDT) Received: by 10.11.100.73 with HTTP; Mon, 5 Sep 2005 17:01:23 -0700 (PDT) Message-ID: Date: Mon, 5 Sep 2005 20:01:23 -0400 From: Tom St Denis To: freebsd-amd64@freebsd.org In-Reply-To: <20050905235554.GA93379@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050905235554.GA93379@dragon.NUXI.org> Cc: shellreef+freebsd@gmail.com Subject: Re: [PATCH] LibTomCrypt on amd64 and -fPIC 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, 06 Sep 2005 00:01:24 -0000 On 9/5/05, David O'Brien wrote: > On Wed, Aug 24, 2005 at 07:18:18PM -0700, shellreef@gmail.com wrote: > > To FreeBSD-amd64: Can we add -fPIC to make.conf? Are there any > > side-effects? (I'd prefer this as I use packages and would prefer to > > not compile from ports.) >=20 > No. -fPIC should only be used to build shared libraries. Not every > since piece of code compiled for AMD64. If the library doesn't build without -fPIC it's because they're using a custom compiler. I've built LTC on 4.0.1, 3.4.4, 3.3.6 and 2.96 boxes [it isn't stable on 4.01, 3.3.6 but it at least builds]. Tom From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 07:46: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 5805716A41F for ; Tue, 6 Sep 2005 07:46:20 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.178.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD8C643D46 for ; Tue, 6 Sep 2005 07:46:19 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from [217.185.89.35] (manz-d9b95923.pool.mediaWays.net [217.185.89.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate1.zdv.Uni-Mainz.DE (Postfix) with ESMTP id 489C33000542; Tue, 6 Sep 2005 09:46:17 +0200 (CEST) Message-ID: <431D4944.9020907@mail.uni-mainz.de> Date: Tue, 06 Sep 2005 09:46:12 +0200 From: "O. Hartmann" Organization: Institut =?ISO-8859-1?Q?f=FCr_Geophysik?= User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <4316A5BC.1000405@meijome.net> <20050906000016.GA91835@xor.obsecurity.org> In-Reply-To: <20050906000016.GA91835@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Cc: freebsd-amd64@freebsd.org Subject: Re: Which SCHED_ for DB server X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2005 07:46:20 -0000 Kris Kennaway wrote: >On Thu, Sep 01, 2005 at 10:53:39AM +0200, Claus Guttesen wrote: > > >>>I'm building a server that will run PostgreSQL with a database >>>containing several 10s of million records. The only things happening on >>>this box will be the SQL processes and other processes to parse raw data >>>and load into the DB. Users = a few connections via HTTP from an >>>intranet server (not more than 5 concurrently). >>> >>>I was wondering what is the best SCHED_ to set in the kernel. >>>I currently have SCHED_4BSD but was wondering if _ULE would be better >>>for this >>> >>> >>For prod. use I would recommend SCHED_4BSD atm. The 4BSD-scheduler >>does seem to be more stable on SMP and up. >> >> > >ULE might be OK on SMP with 6.0 and above, but performance seems to be >a bit lower than 4BSD in my tests. Try it yourself and see which is >better. > >Kris > > Interesting. An, by the way, what are the benefits of ULE at this moment? Is it still a more experimental scheduler for the far future on SMP based machines or do we have benefits in UP/SMP? From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 08:22: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 0733C16A41F for ; Tue, 6 Sep 2005 08:22:37 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84DAE43D49 for ; Tue, 6 Sep 2005 08:22:36 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j868MZvf012792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2005 04:22:35 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j868MY6P011039; Tue, 6 Sep 2005 04:22:35 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 50D8251506; Tue, 6 Sep 2005 04:22:33 -0400 (EDT) Date: Tue, 6 Sep 2005 04:22:30 -0400 From: Kris Kennaway To: "O. Hartmann" Message-ID: <20050906082229.GA27104@xor.obsecurity.org> References: <4316A5BC.1000405@meijome.net> <20050906000016.GA91835@xor.obsecurity.org> <431D4944.9020907@mail.uni-mainz.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <431D4944.9020907@mail.uni-mainz.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org, Kris Kennaway Subject: Re: Which SCHED_ for DB server X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2005 08:22:37 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 06, 2005 at 09:46:12AM +0200, O. Hartmann wrote: > Kris Kennaway wrote: >=20 > >On Thu, Sep 01, 2005 at 10:53:39AM +0200, Claus Guttesen wrote: > >=20 > > > >>>I'm building a server that will run PostgreSQL with a database > >>>containing several 10s of million records. The only things happening on > >>>this box will be the SQL processes and other processes to parse raw da= ta > >>>and load into the DB. Users =3D a few connections via HTTP from an > >>>intranet server (not more than 5 concurrently). > >>> > >>>I was wondering what is the best SCHED_ to set in the kernel. > >>>I currently have SCHED_4BSD but was wondering if _ULE would be better > >>>for this > >>> =20 > >>> > >>For prod. use I would recommend SCHED_4BSD atm. The 4BSD-scheduler > >>does seem to be more stable on SMP and up. > >> =20 > >> > > > >ULE might be OK on SMP with 6.0 and above, but performance seems to be > >a bit lower than 4BSD in my tests. Try it yourself and see which is > >better. > > > >Kris > >=20 > > > Interesting. > An, by the way, what are the benefits of ULE at this moment? Is it still= =20 > a more experimental scheduler for the far future on SMP based machines=20 > or do we have benefits in UP/SMP? It was supposed to provide higher performance (and did for a while, modulo panics), but at the moment it still needs work. Kris --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDHVHFWry0BWjoQKURArKcAJ9P0zQD5yDD++PrrYTqUB/HV/H5bgCaAh9Q jeBmjzpe8E5yA6kZE7yov/g= =ahHl -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 08:29: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 0846F16A41F for ; Tue, 6 Sep 2005 08:29:06 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E6C843D48 for ; Tue, 6 Sep 2005 08:29:05 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j868T4vf013231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2005 04:29:04 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j868T46P011343; Tue, 6 Sep 2005 04:29:04 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3345651287; Tue, 6 Sep 2005 04:29:04 -0400 (EDT) Date: Tue, 6 Sep 2005 04:29:04 -0400 From: Kris Kennaway To: Tom St Denis Message-ID: <20050906082904.GA27179@xor.obsecurity.org> References: <20050905235554.GA93379@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: shellreef+freebsd@gmail.com, freebsd-amd64@freebsd.org Subject: Re: [PATCH] LibTomCrypt on amd64 and -fPIC 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, 06 Sep 2005 08:29:06 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 05, 2005 at 08:01:23PM -0400, Tom St Denis wrote: > On 9/5/05, David O'Brien wrote: > > On Wed, Aug 24, 2005 at 07:18:18PM -0700, shellreef@gmail.com wrote: > > > To FreeBSD-amd64: Can we add -fPIC to make.conf? Are there any > > > side-effects? (I'd prefer this as I use packages and would prefer to > > > not compile from ports.) > >=20 > > No. -fPIC should only be used to build shared libraries. Not every > > since piece of code compiled for AMD64. >=20 > If the library doesn't build without -fPIC it's because they're using > a custom compiler. I've built LTC on 4.0.1, 3.4.4, 3.3.6 and 2.96 > boxes [it isn't stable on 4.01, 3.3.6 but it at least builds]. The issue is typically that the software tries to link a static library (i.e. one compiled without -fPIC) against relocatable objects (-fPIC), so the compiler version is not relevant. This is only an issue on some architectures like amd64, ia64 and sparc64. Anyway, this port does seem to compile as-is on amd64. Kris --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDHVNPWry0BWjoQKURAmP4AJ0Rwu25ztDuNHXRXQVzhMZS6GqRYQCePRij k6tusGE3xYvAHO4F5QIeQdY= =DaLO -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 11:54: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 42D6716A41F for ; Tue, 6 Sep 2005 11:54:40 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.178.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id A530B43D45 for ; Tue, 6 Sep 2005 11:54:37 +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 mailgate1.zdv.Uni-Mainz.DE (Postfix) with ESMTP id 8DA6030004E8 for ; Tue, 6 Sep 2005 13:54:36 +0200 (CEST) Message-ID: <431D8365.6030805@mail.uni-mainz.de> Date: Tue, 06 Sep 2005 13:54:13 +0200 From: "O. Hartmann" Organization: Institut =?ISO-8859-15?Q?f=FCr_Geophysik?= User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050829) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Subject: JDK15: Build error on i386 (FBSD 6.0_BETA3) 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, 06 Sep 2005 11:54:40 -0000 Prior to this message I asked for the availability of JAVA for the AMD64 plattform of FreeBSD 6.0. I will ask again due to some problems while installation and compiling on an i386 plattform under FBSD 6.0-BETA3. I downloaded each needed archive by hand as I was instructed by the installation procedure from the ports collection. I was wondering whether I need a working Linux environment. On our lab's i386 machines we have Linuxulator enabled by default, on the amd64 platforms it isn't. The amd64 boxes are pure 64Bit platforms and the do not have a 64Bit Linuxulator under FBSD 6.0, I remember. On those boxes, the installation stops immediately due to the lack of the Linux environment. On i386 boxes I receive the attached error while installation. This is really a kind of 'funny', because I got this error very often on all FreeBSD boxes (5.X - 6.0). I have no clue why. It is frustrating to need a 32Bit environment while installation on amd64 platforms with no 32Bit support enabled. Is there something wrong with my environment, my view of things running or is there really a problem with JAVA on pure 64Bit machines with FBSD 6.0? Oliver ===> Returning to build of jdk-1.5.0p1_3 ===> jdk-1.5.0p1_3 depends on executable: gmake - found ===> Configuring for jdk-1.5.0p1_3 ===> Building for jdk-1.5.0p1_3 # Start of jdk build bsd i586 1.5.0-p1 build started: 05-09-06 11:42 gmake[1]: Entering directory `/usr/ports/java/jdk15/work/j2se/make' gmake[1]: Leaving directory `/usr/ports/java/jdk15/work/j2se/make' Build Machine Information: build machine = Build Directory Structure: CWD = /usr/ports/java/jdk15/work/control/make TOPDIR = ./../.. CONTROL_TOPDIR = ./../../control HOTSPOT_TOPDIR = ./../../hotspot J2SE_TOPDIR = ./../../j2se DEPLOY_TOPDIR = ./../../deploy INSTALL_TOPDIR = ./../../install Build Directives: BUILD_HOTSPOT = true BUILD_MOTIF = false BUILD_INSTALL = true Hotspot Settings: HOTSPOT_BUILD_JOBS = Bootstrap Settings: BOOTDIR = /usr/local/linux-sun-jdk1.4.2 BOOTSTRAP J2SDK VERSION: Segmentation fault OUTPUTDIR = /usr/ports/java/jdk15/work/control/build/bsd-i586 Build Tool Settings: UNIXCOMMAND_PATH = /bin/ COMPILER_PATH = /usr/bin/ DEVTOOLS_PATH = /usr/local/bin/ USRBIN_PATH = /usr/bin/ MOTIF_DIR = /usr/X11R6 CC_VER = 3.4.4 ZIP_VER = 2.3 PATH = /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/usr/local/samba/bin:/usr/local/mysql/bin:/root/bin:/usr/local/scripts/admin:/usr/local/scripts/public:usr/local/gmt/bin TMPDIR = /usr/ports/java/jdk15/work/control/build/bsd-i586/tmp Build Directives: USE_ONLY_BOOTDIR_TOOLS = USE_HOTSPOT_INTERPRETER_MODE = PEDANTIC = DEV_ONLY = J2RE_ONLY = NO_DOCS = NO_IMAGES = TOOLS_ONLY = INSANE = PARALLEL_COMPILES = false PARALLEL_COMPILE_JOBS = 2 FASTDEBUG = false INCREMENTAL_BUILD = false Build Platform Settings: PLATFORM = bsd ARCH = i586 LIBARCH = i386 ARCH_FAMILY = i586 ARCH_DATA_MODEL = 32 TRUE_PLATFORM = FreeBSD OS_VERSION = 6.0-BETA3 FREE_SPACE = 11341540 GNU Make Settings: MAKE = gmake MAKE VERSION = MAKECMDGOALS = sanity MAKEFLAGS = SHELL = /bin/sh Target Build Versions: JDK_VERSION = 1.5.0 MILESTONE = p1 BUILD_NUMBER = root_06_sep_2005_11_42 External File/Binary Locations: HOTSPOT_SERVER_PATH = /usr/ports/java/jdk15/work/control/build/bsd-i586/hotspot-i586/server HOTSPOT_CLIENT_PATH = /usr/ports/java/jdk15/work/control/build/bsd-i586/hotspot-i586/client HOTSPOT_IMPORT_PATH = /usr/ports/java/jdk15/work/control/build/bsd-i586/hotspot-i586/import MOTIF_DIR = /usr/X11R6 CACERTS_FILE = ./../src/share/lib/security/cacerts ERROR: Your BOOTDIR environment variable does not point to a valid Java 2 SDK for bootstrapping this build. A Java 2 SDK 1.5.0 build must be bootstrapped using J2SDK 1.4.2 fcs (or later). Apparently, your bootstrap JDK is version Segmentation fault Please update your ALT_BOOTDIR setting and start your build again. Exiting because of the above error(s). gmake: *** [post-sanity] Error 1 *** Error code 2 Stop in /usr/ports/java/jdk15. From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 12:52: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 168D516A41F; Tue, 6 Sep 2005 12:52:10 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.178.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD24543D49; Tue, 6 Sep 2005 12:52:09 +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 mailgate1.zdv.Uni-Mainz.DE (Postfix) with ESMTP id 9FC0B30005B2; Tue, 6 Sep 2005 14:52:08 +0200 (CEST) Message-ID: <431D90E1.1030105@mail.uni-mainz.de> Date: Tue, 06 Sep 2005 14:51:45 +0200 From: "O. Hartmann" Organization: Institut =?ISO-8859-15?Q?f=FCr_Geophysik?= User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050829) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Cc: Subject: nForce4-SLI, AHCI and NCQ and FreeBSD 6.0 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, 06 Sep 2005 12:52:10 -0000 Hello. I have a little question about the popular nForce4-SLI chipset for the Socket 939 platform. The onboard SATA controller of the nForce4-SLI chipset claims to be NCQ (or SATA II) capable, but nVidia implemented this feature in a not-AHCI-standardised way, but as an own solution. My question is: Is the FBSD 6.X driver for the nForce4-SLI chipset capable of using NCQ (as I know, the driver has to enable NCQ and it's not done automatically by the harddrive-controller interaction). Thanks in advance, Oliver From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 13:01: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 6807A16A41F for ; Tue, 6 Sep 2005 13:01:16 +0000 (GMT) (envelope-from skreetch_fr@yahoo.fr) Received: from smtp-out.completel.net (smtp-out.completel.net [83.145.110.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id A414E43D46 for ; Tue, 6 Sep 2005 13:01:15 +0000 (GMT) (envelope-from skreetch_fr@yahoo.fr) Received: from noc-supp-serv-1.completel.lan (fwa.completel.fr [213.30.170.197]) by smtp-out.completel.net (Postfix) with ESMTP id 33B13280060 for ; Tue, 6 Sep 2005 15:01:13 +0200 (CEST) Received: from [10.129.1.190] ([10.129.1.190]) (authenticated bits=0) by noc-supp-serv-1.completel.lan (8.13.4/8.13.3) with ESMTP id j86CvREh032130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Sep 2005 14:57:42 +0200 (CEST) (envelope-from skreetch_fr@yahoo.fr) Message-ID: <431D9211.8050704@yahoo.fr> Date: Tue, 06 Sep 2005 14:56:49 +0200 From: Skreetch User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <43023088.90500@yahoo.fr> <20050904081029.GE20880@dragon.NUXI.org> In-Reply-To: <20050904081029.GE20880@dragon.NUXI.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on noc-supp-serv-1.completel.lan X-Virus-Scanned: ClamAV 0.86.2/1065/Tue Sep 6 09:20:15 2005 on noc-supp-serv-1.completel.lan X-Virus-Status: Clean Subject: Re: Openoffice 1.1 with gcc-ooo 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, 06 Sep 2005 13:01:16 -0000 Maho's comment on the OOo ports Friday is clear: "Only buildable/working on i386" Thanks for your answers. Skreetch David O'Brien a écrit : > On Tue, Aug 16, 2005 at 08:29:28PM +0200, Skreetch wrote: > >>I'd like to install OpenOffice 1.1 using the ports collection > > > OpenOffice isn't 64-bit clean, and one one has figured out how to > co-install 32-bit and 64-bit ports. So even if gcc-ooo would build, you > woundn't get anywhere. > From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 13:01: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 6F99616A420 for ; Tue, 6 Sep 2005 13:01:16 +0000 (GMT) (envelope-from skreetch_fr@yahoo.fr) Received: from smtp-out.completel.net (smtp-out.completel.net [83.145.110.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id A42B043D49 for ; Tue, 6 Sep 2005 13:01:15 +0000 (GMT) (envelope-from skreetch_fr@yahoo.fr) Received: from noc-supp-serv-1.completel.lan (fwa.completel.fr [213.30.170.197]) by smtp-out.completel.net (Postfix) with ESMTP id 3D93E28005B for ; Tue, 6 Sep 2005 15:01:13 +0200 (CEST) Received: from [10.129.1.190] ([10.129.1.190]) (authenticated bits=0) by noc-supp-serv-1.completel.lan (8.13.4/8.13.3) with ESMTP id j868R5QN006748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Sep 2005 10:27:13 +0200 (CEST) (envelope-from skreetch_fr@yahoo.fr) Message-ID: <431D52B1.508@yahoo.fr> Date: Tue, 06 Sep 2005 10:26:25 +0200 From: Skreetch User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <43023088.90500@yahoo.fr> <20050904081029.GE20880@dragon.NUXI.org> In-Reply-To: <20050904081029.GE20880@dragon.NUXI.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on noc-supp-serv-1.completel.lan X-Virus-Scanned: ClamAV 0.86.2/1065/Tue Sep 6 09:20:15 2005 on noc-supp-serv-1.completel.lan X-Virus-Status: Clean Subject: Re: Openoffice 1.1 with gcc-ooo 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, 06 Sep 2005 13:01:16 -0000 Maho's comment on the OOo ports Friday is clear: "Only buildable/working on i386" Thanks for your answers. Skreetch David O'Brien a écrit : > On Tue, Aug 16, 2005 at 08:29:28PM +0200, Skreetch wrote: > >>I'd like to install OpenOffice 1.1 using the ports collection > > > OpenOffice isn't 64-bit clean, and one one has figured out how to > co-install 32-bit and 64-bit ports. So even if gcc-ooo would build, you > woundn't get anywhere. > From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 13:47: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 6D65C16A41F for ; Tue, 6 Sep 2005 13:47:43 +0000 (GMT) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBB3A43D66 for ; Tue, 6 Sep 2005 13:47:42 +0000 (GMT) (envelope-from freebsd@meijome.net) Received: (qmail 21365 invoked from network); 6 Sep 2005 23:47:42 +1000 Received: from 203-173-33-12.dyn.iinet.net.au (HELO ?192.168.13.3?) (203.173.33.12) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Sep 2005 23:47:42 +1000 Message-ID: <431D9DF9.3000706@meijome.net> Date: Tue, 06 Sep 2005 23:47:37 +1000 From: Norberto Meijome User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <4316A5BC.1000405@meijome.net> <20050906000016.GA91835@xor.obsecurity.org> <431D4944.9020907@mail.uni-mainz.de> <20050906082229.GA27104@xor.obsecurity.org> In-Reply-To: <20050906082229.GA27104@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "O. Hartmann" , freebsd-amd64@freebsd.org Subject: Re: Which SCHED_ for DB server X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2005 13:47:43 -0000 Kris Kennaway wrote: >> >>Interesting. >>An, by the way, what are the benefits of ULE at this moment? Is it still >>a more experimental scheduler for the far future on SMP based machines >>or do we have benefits in UP/SMP? > > > It was supposed to provide higher performance (and did for a while, > modulo panics), but at the moment it still needs work. > > Kris Thanks everyone for the comments. BTW, this is only a minimal SMP system (2 way Opteron), so not sure whether it'd make much difference anyway. using 4BSD for now until I have some real-world apps running in order to test. btw, any chance of other schedulers being added to fbsd, like the staircase sched found in linux , or maybe others? (not offering as I can't code @ that level, just curious) thanks again, beto From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 14:09: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 2A82E16A420 for ; Tue, 6 Sep 2005 14:09:02 +0000 (GMT) (envelope-from malachid@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id F032743D46 for ; Tue, 6 Sep 2005 14:09:00 +0000 (GMT) (envelope-from malachid@gmail.com) Received: by wproxy.gmail.com with SMTP id 36so1191003wra for ; Tue, 06 Sep 2005 07:09:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tZVZDjhDpJqxelsximfcBFFE32Wq++wLBWEoNoKciwCAa82lCOhLMMCkrLOXZPvDCBEu1axSqlDmLqEOfvGb1DcpFdZdcjEm5PnG7DaryZKH/ATBeJekN3a9QElNVAIk+CCN/dfY1oIIGUYpoZKrQvgqh0Eb/iM8L348OuXaYmo= Received: by 10.54.29.44 with SMTP id c44mr1375466wrc; Tue, 06 Sep 2005 07:08:59 -0700 (PDT) Received: by 10.54.79.1 with HTTP; Tue, 6 Sep 2005 07:08:59 -0700 (PDT) Message-ID: Date: Tue, 6 Sep 2005 07:08:59 -0700 From: =?ISO-8859-1?Q?Malachi_de_=C6lfweald?= To: "O. Hartmann" In-Reply-To: <431D90E1.1030105@mail.uni-mainz.de> Mime-Version: 1.0 References: <431D90E1.1030105@mail.uni-mainz.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-questions@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: nForce4-SLI, AHCI and NCQ and FreeBSD 6.0 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, 06 Sep 2005 14:09:02 -0000 I have noticed the same thing with the onboard Silicon Image controller. I= =20 am using the A8N-SLI Premium. I am using the Silicon Image controller=20 instead of the nForce4 controller because it specifically said SATAII and= =20 said it supported RAID5 (whereas the nForce did not support RAID5). However= ,=20 on boot it recognizes it as SATA150 (which should be SATA300). Malachi On 9/6/05, O. Hartmann wrote: >=20 > Hello. > I have a little question about the popular nForce4-SLI chipset for the > Socket 939 platform. The onboard SATA controller of the nForce4-SLI > chipset claims to be NCQ (or SATA II) capable, but nVidia implemented > this feature in a not-AHCI-standardised way, but as an own solution. My > question is: Is the FBSD 6.X driver for the nForce4-SLI chipset capable > of using NCQ (as I know, the driver has to enable NCQ and it's not done > automatically by the harddrive-controller interaction). >=20 > Thanks in advance, > Oliver > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" > From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 15:00:41 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 5B02616A41F for ; Tue, 6 Sep 2005 15:00:41 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (koyukuk.teamcool.net [209.161.34.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0262F43D46 for ; Tue, 6 Sep 2005 15:00:40 +0000 (GMT) (envelope-from kgunders@teamcool.net) Received: from koyukuk.teamcool.net (localhost [127.0.0.1]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 90D8611EE4 for ; Tue, 6 Sep 2005 09:00:35 -0600 (MDT) Received: from cochise.teamcool.net (unknown [192.168.1.57]) by koyukuk.teamcool.net (TeamCool Rocks) with ESMTP id 5A00711EE3 for ; Tue, 6 Sep 2005 09:00:35 -0600 (MDT) Date: Tue, 6 Sep 2005 09:00:34 -0600 From: Ken Gunderson To: freebsd-amd64@freebsd.org Message-Id: <20050906090034.17d2feba.kgunders@teamcool.net> In-Reply-To: <431D90E1.1030105@mail.uni-mainz.de> References: <431D90E1.1030105@mail.uni-mainz.de> Organization: Teamcool Networks X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: nForce4-SLI, AHCI and NCQ and FreeBSD 6.0 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, 06 Sep 2005 15:00:41 -0000 On Tue, 06 Sep 2005 14:51:45 +0200 "O. Hartmann" wrote: > Hello. > I have a little question about the popular nForce4-SLI chipset for the > Socket 939 platform. The onboard SATA controller of the nForce4-SLI > chipset claims to be NCQ (or SATA II) capable, but nVidia implemented > this feature in a not-AHCI-standardised way, but as an own solution. My > question is: Is the FBSD 6.X driver for the nForce4-SLI chipset capable > of using NCQ (as I know, the driver has to enable NCQ and it's not done > automatically by the harddrive-controller interaction). Along similar lines, is anyone aware of any VIA based boards that even support SATAII? From what I understand the VIA VT8237 is limited to SATA I and it's successor is still quite a way away from production release. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 15:05: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 7456D16A41F for ; Tue, 6 Sep 2005 15:05:06 +0000 (GMT) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (glewis.dsl.xmission.com [166.70.56.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id D541843D45 for ; Tue, 6 Sep 2005 15:05:05 +0000 (GMT) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.13.3/8.13.3) with ESMTP id j86F53pS060591; Tue, 6 Sep 2005 09:05:03 -0600 (MDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.13.3/8.13.3/Submit) id j86F52b1060590; Tue, 6 Sep 2005 09:05:02 -0600 (MDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Tue, 6 Sep 2005 09:05:02 -0600 From: Greg Lewis To: "O. Hartmann" Message-ID: <20050906150502.GA60550@misty.eyesbeyond.com> References: <431D8365.6030805@mail.uni-mainz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <431D8365.6030805@mail.uni-mainz.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: JDK15: Build error on i386 (FBSD 6.0_BETA3) 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, 06 Sep 2005 15:05:06 -0000 On Tue, Sep 06, 2005 at 01:54:13PM +0200, O. Hartmann wrote: > Prior to this message I asked for the availability of JAVA for the AMD64 > plattform of FreeBSD 6.0. I will ask again due to some problems while > installation and compiling on an i386 plattform under FBSD 6.0-BETA3. > > I downloaded each needed archive by hand as I was instructed by the > installation procedure from the ports collection. I was wondering > whether I need a working Linux environment. On our lab's i386 machines > we have Linuxulator enabled by default, on the amd64 platforms it isn't. > The amd64 boxes are pure 64Bit platforms and the do not have a 64Bit > Linuxulator under FBSD 6.0, I remember. On those boxes, the installation > stops immediately due to the lack of the Linux environment. > > On i386 boxes I receive the attached error while installation. This is > really a kind of 'funny', because I got this error very often on all > FreeBSD boxes (5.X - 6.0). I have no clue why. This error indicates that the Linux JDK can't be run. Try running it by hand. Usually this means Linux emulation isn't enabled, although you've said that it is. > It is frustrating to need a 32Bit environment while installation on > amd64 platforms with no 32Bit support enabled. > > Is there something wrong with my environment, my view of things running > or is there really a problem with JAVA on pure 64Bit machines with FBSD 6.0? You need to bootstrap the build with _something_. Currently that something is the 32 bit Linux JDK. Once the build is complete you can remove it. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 19:11: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 C95ED16A41F; Tue, 6 Sep 2005 19:11:16 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88F3443D4C; Tue, 6 Sep 2005 19:11:12 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.13.4/8.13.4/Debian-3) with ESMTP id j86JBAnZ020189; Tue, 6 Sep 2005 21:11:10 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id j86JBA8T020187; Tue, 6 Sep 2005 21:11:10 +0200 Received: from saturn.kn-bremen.de (localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.1/8.13.1) with ESMTP id j86J81md009197; Tue, 6 Sep 2005 21:08:01 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.1/8.13.1/Submit) id j86J81jw009196; Tue, 6 Sep 2005 21:08:01 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Tue, 6 Sep 2005 21:07:53 +0200 To: qemu-devel@nongnu.org, freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org Message-ID: <20050906190753.GA8560@saturn.kn-bremen.de> Mail-Followup-To: qemu-devel@nongnu.org, freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: FreeBSD qemu port update - some success with kqemu/amd64 :) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2005 19:11:17 -0000 KNOPPIX_V3.7-2004-12-08-DE.iso now seems to work in qemu-system-x86_64 when booted with 2.4 kernel (yeah!), the 2.6 kernel (booted with `knoppix26 vga=0') crashes after printing `checking if image is initramfs...', both with and without kqemu: qemu: fatal: Trying to execute code outside RAM or ROM at 0xffffffffc00f9ca0 EAX=49435024 EBX=00000000 ECX=00000000 EDX=00000010 ESI=00000286 EDI=c0361424 EBP=00000000 ESP=c1251f94 EIP=c00f9ca0 EFL=00000002 [-------] CPL=0 II=0 A20=1 ES =007b 00000000 ffffffff 00cff300 CS =0060 00000000 ffffffff 00cf9a00 SS =0068 00000000 ffffffff 00cf9300 DS =007b 00000000 ffffffff 00cff300 FS =0000 00000000 00000000 00000000 GS =0000 00000000 00000000 00000000 LDT=0088 c03f1ba0 00000027 c000823f TR =0080 c1102060 00002073 c1008910 GDT= c1104260 000000ff IDT= c039a000 000007ff CR0=8005003b CR2=ffe3e000 CR3=003ef000 CR4=00000690 CCS=00000008 CCD=00000000 CCO=LOGICL FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=800bf60000000000 4015 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 Abort trap (core dumped) 5.4-RELEASE-amd64-disc1.iso with kqemu hangs after printing `Mounting root from ufs:/dev/md0', eating CPU; apparently it fails to enter userland (next message without kqemu is `/stand/sysinstall running as init on vty0', then comes the sysinstall menu.) 5.4-RELEASE-i386-disc1.iso still panics at 0x8:0xc0762fbc, both with and witout kqemu (see my first post about qemu-system-x86_64 for details.) KANOTIX-2005-03.iso (2.6.11 kernel) crashes after printing `Freeing initrd memory', sometimes it even gets one line further, printing `NET: registered protocol family 16', both with and without kqemu. Crash otherwise looks very similar to knoppix: qemu: fatal: Trying to execute code outside RAM or ROM at 0xffffffffc00f9ca0 EAX=49435024 EBX=00000000 ECX=00000000 EDX=00000010 ESI=00000000 EDI=c0481764 EBP=00000287 ESP=c7e81f9c EIP=c00f9ca0 EFL=00000002 [-------] CPL=0 II=0 A20=1 ES =007b 00000000 ffffffff 00cff300 CS =0060 00000000 ffffffff 00cf9a00 SS =0068 00000000 ffffffff 00cf9300 DS =007b 00000000 ffffffff 00cff300 FS =0000 00000000 00000000 00000000 GS =0000 00000000 00000000 00000000 LDT=0088 c0509a40 00000027 c0008250 TR =0080 c0427040 00002073 c0008942 GDT= c050b0e0 000000ff IDT= c04bc000 000007ff CR0=8005003b CR2=fffd9000 CR3=00507000 CR4=00000690 CCS=40000000 CCD=00000000 CCO=LOGICL FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=800bf60000000000 4015 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 Abort trap (core dumped) Here comes the update, please test! if no new problems show up i think this can be committed... - first (partly) working kqemu/amd64 version - added a note about RELENG_6 guests to pkg-message (PREEMPTION) Removed files: files/BSDmakefile files/kmod_bsd.c New files: files/kqemu-freebsd-patch files/patch-libmath2 files/patch-vl.c Index: Makefile =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/Makefile,v retrieving revision 1.27 diff -u -r1.27 Makefile --- Makefile 19 Jul 2005 06:06:56 -0000 1.27 +++ Makefile 6 Sep 2005 18:02:11 -0000 @@ -6,12 +6,11 @@ # PORTNAME= qemu -PORTVERSION= 0.7.0s.20050717 +PORTVERSION= 0.7.2 CATEGORIES= emulators MASTER_SITES= http://www.qemu.org/ \ http://people.fruitsalad.org/nox/qemu/ \ http://dad-answers.com/qemu/ -DISTNAME= ${PORTNAME}-snapshot-2005-07-17_23 EXTRACT_ONLY= ${DISTNAME}${EXTRACT_SUFX} MAINTAINER= nox@jelal.kn-bremen.de @@ -23,12 +22,12 @@ .endif .if defined(WITH_KQEMU) -DISTKQEMU= kqemu-0.6.2-1.tar.gz +DISTKQEMU= kqemu-0.7.2.tar.gz DISTFILES= ${EXTRACT_ONLY} ${DISTKQEMU} +EXTRA_PATCHES= ${FILESDIR}/kqemu-freebsd-patch .endif HAS_CONFIGURE= yes -USE_BZIP2= yes USE_GMAKE= yes USE_GETOPT_LONG= yes USE_SDL= sdl @@ -40,9 +39,11 @@ ONLY_FOR_ARCHS= amd64 i386 .if defined(WITH_KQEMU) NO_PACKAGE= Depends on kernel, and module not redistributable +CONFIGURE_ARGS+= --enable-kqemu PLIST_SUB= WITH_KQEMU="" PLIST_SUB+= KMODDIR=${KMODDIR} .else +CONFIGURE_ARGS+= --disable-kqemu PLIST_SUB= WITH_KQEMU="@comment " .endif @@ -52,7 +53,7 @@ .if ${ARCH} == "amd64" ARCH= x86_64 -.if ${OSVERSION} >= 502126 +.if ${OSVERSION} >= 502126 && ${OSVERSION} <= 600029 BUILD_DEPENDS+= gcc34:${PORTSDIR}/lang/gcc34 GCCVERSION= 030402 CC= gcc34 @@ -63,16 +64,12 @@ USE_GCC= 3.4 .endif -.if defined(WITH_KQEMU) && ${ARCH} != "i386" -IGNORE= kqemu only supported on i386 -.endif - .if defined(WITH_KQEMU) && !exists(${SRC_BASE}/sys/Makefile) IGNORE= kqemu requires kernel source to be installed .endif pre-everything:: -.if !defined(WITH_KQEMU) && ${ARCH} == "i386" +.if !defined(WITH_KQEMU) @${ECHO_MSG} "Notice: you can build qemu with the (alpha!) kqemu accelerator kernel module" @${ECHO_MSG} "by defining WITH_KQEMU." .endif @@ -85,7 +82,7 @@ .if defined(WITH_KQEMU) post-extract: @cd ${WRKSRC} && ${TAR} xfz ${_DISTDIR}/${DISTKQEMU} - @${CP} ${FILESDIR}/BSDmakefile ${FILESDIR}/kmod_bsd.c ${WRKSRC}/kqemu + @${LN} -s Makefile.freebsd ${WRKSRC}/kqemu/BSDmakefile .endif pre-patch: Index: distinfo =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/distinfo,v retrieving revision 1.20 diff -u -r1.20 distinfo --- distinfo 19 Jul 2005 06:06:56 -0000 1.20 +++ distinfo 6 Sep 2005 18:02:22 -0000 @@ -1,4 +1,4 @@ -MD5 (qemu-snapshot-2005-07-17_23.tar.bz2) = 5d21295c1f328ea00de19a54715ee7c3 -SIZE (qemu-snapshot-2005-07-17_23.tar.bz2) = 1114748 -MD5 (kqemu-0.6.2-1.tar.gz) = c6bb3b40fb3d526d731eb0f1f9dee7ee -SIZE (kqemu-0.6.2-1.tar.gz) = 21002 +MD5 (qemu-0.7.2.tar.gz) = 7d69dd96edf7ae5298a9a7283a0e9fb8 +SIZE (qemu-0.7.2.tar.gz) = 1341993 +MD5 (kqemu-0.7.2.tar.gz) = 02cfdecda90458d6393781496ec6b48b +SIZE (kqemu-0.7.2.tar.gz) = 79314 Index: pkg-message =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/pkg-message,v retrieving revision 1.8 diff -u -r1.8 pkg-message --- pkg-message 1 May 2005 07:39:10 -0000 1.8 +++ pkg-message 6 Sep 2005 18:23:22 -0000 @@ -1,6 +1,9 @@ ==== FreeBSD host notes: - needs to run as root in order to use /dev/tap* networking (why?) +(actually RELENG_6 and above now has a sysctl net.link.tap.user_open +to allow users to use it too. don't forget to adjust device node +permissions in /etc/devfs.rules.) - slirp (usermode networking) is fixed now in cvs, on FreeSBIE 1.0 guests you still have to manually do: echo nameserver 10.0.2.3 >/etc/resolv.conf @@ -18,4 +21,9 @@ ioctl.) - the -smb option (smb-export local dir to guest) needs the net/samba port/package installed in addition to qemu. +- RELENG_6 and up guests often crash while accessing the emulated cdrom +(see kern/84102, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84102), +using a kernel without PREEMPTION has been reported to fix this problem. +(or do an ftp install instead of installing from the emulated cdrom, and +then make a new kernel.) ==== Index: files/patch-fbsd =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/files/patch-fbsd,v retrieving revision 1.2 diff -u -r1.2 patch-fbsd --- files/patch-fbsd 5 May 2005 12:41:10 -0000 1.2 +++ files/patch-fbsd 11 Aug 2005 16:38:42 -0000 @@ -13,7 +13,7 @@ $(MAKE) -C kqemu -f Makefile.winnt else - $(MAKE) -C kqemu -+ cd kqemu && $(BSD_MAKE) ++ ( cd kqemu && $(BSD_MAKE) ) endif endif Index: files/kqemu-freebsd-patch @@ -0,0 +1,501 @@ +Index: qemu/kqemu/Makefile.freebsd +@@ -1,9 +1,13 @@ ++# $Id: Makefile.freebsd,v 1.1 2005/04/17 17:21:31 bellard Exp $ + KMOD= kqemu + SRCS= kqemu-freebsd.c + .if ${MACHINE_ARCH} == "i386" + OBJS= kqemu-mod-i386.o + .elif ${MACHINE_ARCH} == "amd64" + OBJS= kqemu-mod-x86_64.o ++.endif ++.if ${OSVERSION} >= 500000 ++CC= cc + .endif + WERROR= + +Index: qemu/kqemu/kqemu-freebsd.c +@@ -3,20 +3,33 @@ + #include + #include + #include ++#include ++#include + #include + #include + #include + #include + #include ++#include ++#if __FreeBSD_version >= 500000 + #include ++#endif + #include + #include ++#include ++#include ++#if __FreeBSD_version < 500000 ++#include ++#endif ++ + #include + #include + #include + #include + #include + #include ++#include ++ + #include + #include + +@@ -27,10 +40,14 @@ + MALLOC_DECLARE(M_KQEMU); + MALLOC_DEFINE(M_KQEMU, "kqemu", "kqemu buffers"); + ++int kqemu_debug; ++SYSCTL_INT(_debug, OID_AUTO, kqemu_debug, CTLFLAG_RW, &kqemu_debug, 0, ++ "kqemu debug flag"); ++ + #define USER_BASE 0x1000 + + /* lock the page at virtual address 'user_addr' and return its +- physical page index. Return -1 if error */ ++ physical page index. Return NULL if error */ + struct kqemu_user_page *CDECL kqemu_lock_user_page(unsigned long *ppage_index, + unsigned long user_addr) + { +@@ -39,14 +56,18 @@ + vm_paddr_t pa = 0; + int ret; + pmap_t pmap; ++#if __FreeBSD_version >= 500000 + ret = vm_map_wire(&vm->vm_map, va, va+PAGE_SIZE, VM_MAP_WIRE_USER); ++#else ++ ret = vm_map_user_pageable(&vm->vm_map, va, va+PAGE_SIZE, FALSE); ++#endif + if (ret != KERN_SUCCESS) { +- printf("kqemu_lock_user_page(%08lx) failed, ret=%d\n", user_addr, ret); ++ kqemu_log("kqemu_lock_user_page(%08lx) failed, ret=%d\n", user_addr, ret); + return NULL; + } + pmap = vm_map_pmap(&vm->vm_map); + pa = pmap_extract(pmap, va); +- // printf("kqemu_lock_user_page(%08lx) va=%08x pa=%08x\n", user_addr, va, pa); ++ // kqemu_log("kqemu_lock_user_page(%08lx) va=%08x pa=%08x\n", user_addr, va, pa); + *ppage_index = pa >> PAGE_SHIFT; + return (struct kqemu_user_page *)va; + } +@@ -56,12 +77,16 @@ + struct vmspace *vm = curproc->p_vmspace; + vm_offset_t va; + int ret; +- // printf("kqemu_unlock_user_page(%08lx)\n", page_index); ++ // kqemu_log("kqemu_unlock_user_page(%08lx)\n", page_index); + va = (vm_offset_t)page; ++#if __FreeBSD_version >= 500000 + ret = vm_map_unwire(&vm->vm_map, va, va+PAGE_SIZE, VM_MAP_WIRE_USER); ++#else ++ ret = vm_map_user_pageable(&vm->vm_map, va, va+PAGE_SIZE, TRUE); ++#endif + #if 0 + if (ret != KERN_SUCCESS) { +- printf("kqemu_unlock_user_page(%08lx) failed, ret=%d\n", page_index, ret); ++ kqemu_log("kqemu_unlock_user_page(%08lx) failed, ret=%d\n", page_index, ret); + } + #endif + } +@@ -78,20 +103,21 @@ + + va = kmem_alloc(kernel_map, PAGE_SIZE); + if (va == 0) { +- printf("kqemu_alloc_zeroed_page: NULL\n"); +- return -1; ++ kqemu_log("kqemu_alloc_zeroed_page: NULL\n"); ++ return NULL; + } + pmap = vm_map_pmap(kernel_map); + pa = pmap_extract(pmap, va); +- // printf("kqemu_alloc_zeroed_page: %08x\n", pa); ++ // kqemu_log("kqemu_alloc_zeroed_page: %08x\n", pa); + *ppage_index = pa >> PAGE_SHIFT; + return (struct kqemu_page *)va; + } + + void CDECL kqemu_free_page(struct kqemu_page *page) + { +- // printf("kqemu_free_page(%08lx)\n", page_index); +- /* XXX: do it */ ++ if (kqemu_debug > 0) ++ kqemu_log("kqemu_free_page(%p)\n", page); ++ kmem_free(kernel_map, (vm_offset_t) page, PAGE_SIZE); + } + + /* return kernel address of the physical page page_index */ +@@ -105,42 +131,29 @@ + GB of physical memory */ + void * CDECL kqemu_vmalloc(unsigned int size) + { +- struct vmspace *vm = curproc->p_vmspace; +- vm_offset_t va = USER_BASE; +- int rv; +- if (size % PAGE_SIZE != 0) { +- printf("kqemu_vmalloc(%d) not a multiple of page size\n", size); +- return NULL; +- } +- rv = vm_map_find(&vm->vm_map, NULL, 0, &va, size, 1, +- VM_PROT_ALL, VM_PROT_ALL, 0); +- if (rv != KERN_SUCCESS) { +- printf("kqemu_vmalloc(%d) failed rv=%d\n", size, rv); +- return NULL; +- } +- printf("kqemu_vmalloc(%d): %08x\n", size, va); +- return (void *)va; ++ void *ptr = malloc(size, M_KQEMU, M_WAITOK); ++ if (kqemu_debug > 0) ++ kqemu_log("kqemu_vmalloc(%d): %p\n", size, ptr); ++ return ptr; + } + + void CDECL kqemu_vfree(void *ptr) + { +- printf("kqemu_vfree(%p)\n", ptr); ++ if (kqemu_debug > 0) ++ kqemu_log("kqemu_vfree(%p)\n", ptr); ++ free(ptr, M_KQEMU); + } + + /* return the physical page index for a given virtual page */ + unsigned long CDECL kqemu_vmalloc_to_phys(const void *vaddr) + { +- struct vmspace *vm = curproc->p_vmspace; +- vm_paddr_t pa; +- pmap_t pmap; +- +- pmap = vm_map_pmap(&vm->vm_map); +- pa = pmap_extract(pmap, (vm_offset_t)vaddr); ++ vm_paddr_t pa = vtophys(vaddr); + if (pa == 0) { +- printf("kqemu_vmalloc_to_phys(%p)->error\n", vaddr); ++ kqemu_log("kqemu_vmalloc_to_phys(%p)->error\n", vaddr); + return -1; + } +- printf("kqemu_vmalloc_to_phys(%p)->%08x\n", vaddr, pa); ++ if (kqemu_debug > 0) ++ kqemu_log("kqemu_vmalloc_to_phys(%p)->%08x\n", vaddr, pa); + return pa >> PAGE_SHIFT; + } + +@@ -156,16 +169,48 @@ + { + } + ++#if __FreeBSD_version < 500000 ++static int ++curpriority_cmp(struct proc *p) ++{ ++ int c_class, p_class; ++ ++ c_class = RTP_PRIO_BASE(curproc->p_rtprio.type); ++ p_class = RTP_PRIO_BASE(p->p_rtprio.type); ++ if (p_class != c_class) ++ return (p_class - c_class); ++ if (p_class == RTP_PRIO_NORMAL) ++ return (((int)p->p_priority - (int)curpriority) / PPQ); ++ return ((int)p->p_rtprio.prio - (int)curproc->p_rtprio.prio); ++} ++ ++/* return TRUE if a signal is pending (i.e. the guest must stop ++ execution) */ ++int CDECL kqemu_schedule(void) ++{ ++ struct proc *p = curproc; ++ if (curpriority_cmp(p) > 0) { ++ int s = splhigh(); ++ p->p_priority = MAXPRI; ++ setrunqueue(p); ++ p->p_stats->p_ru.ru_nvcsw++; ++ mi_switch(); ++ splx(s); ++ } ++ return issignal(curproc) != 0; ++} ++#else + /* return TRUE if a signal is pending (i.e. the guest must stop + execution) */ + int CDECL kqemu_schedule(void) + { +- // printf("kqemu_schedule\n"); ++ // kqemu_log("kqemu_schedule\n"); + mtx_lock_spin(&sched_lock); + mi_switch(SW_VOL, NULL); + mtx_unlock_spin(&sched_lock); + return SIGPENDING(curthread); + } ++#endif + + static char log_buf[4096]; + +@@ -178,47 +223,149 @@ + va_end(ap); + } + ++#define KQEMU_MAX_INSTANCES 4 ++ + struct kqemu_instance { ++#if __FreeBSD_version >= 500000 ++ TAILQ_ENTRY(kqemu_instance) kqemu_ent; ++ struct cdev *kqemu_dev; ++#endif + // struct semaphore sem; + struct kqemu_state *state; + }; + ++static int kqemu_ref_count = 0; ++static int max_locked_pages; ++ ++#if __FreeBSD_version < 500000 ++static dev_t kqemu_dev; ++#else ++static struct clonedevs *kqemuclones; ++static TAILQ_HEAD(,kqemu_instance) kqemuhead = TAILQ_HEAD_INITIALIZER(kqemuhead); ++static eventhandler_tag clonetag; ++#endif ++ + static d_close_t kqemu_close; + static d_open_t kqemu_open; + static d_ioctl_t kqemu_ioctl; + + static struct cdevsw kqemu_cdevsw = { ++#if __FreeBSD_version < 500000 ++ /* open */ kqemu_open, ++ /* close */ kqemu_close, ++ /* read */ noread, ++ /* write */ nowrite, ++ /* ioctl */ kqemu_ioctl, ++ /* poll */ nopoll, ++ /* mmap */ nommap, ++ /* strategy */ nostrategy, ++ /* name */ "kqemu", ++ /* maj */ KQEMU_MAJOR, ++ /* dump */ nodump, ++ /* psize */ nopsize, ++ /* flags */ 0, ++ /* bmaj */ -1 ++#else + .d_version = D_VERSION, + .d_flags = D_NEEDGIANT, + .d_open = kqemu_open, + .d_ioctl = kqemu_ioctl, + .d_close = kqemu_close, + .d_name = "kqemu" ++#endif + }; + +-/* For use with make_dev(9)/destroy_dev(9). */ +-static struct cdev *kqemu_dev; ++#if __FreeBSD_version >= 500000 ++static void ++kqemu_clone(void *arg, char *name, int namelen, struct cdev **dev) ++{ ++ int unit, r; ++ if (*dev != NULL) ++ return; ++ ++ if (strcmp(name, "kqemu") == 0) ++ unit = -1; ++ else if (dev_stdclone(name, NULL, "kqemu", &unit) != 1) ++ return; /* Bad name */ ++ if (unit != -1 && unit > KQEMU_MAX_INSTANCES) ++ return; ++ ++ r = clone_create(&kqemuclones, &kqemu_cdevsw, &unit, dev, 0); ++ if (r) { ++ *dev = make_dev(&kqemu_cdevsw, unit2minor(unit), ++ UID_ROOT, GID_WHEEL, 0660, "kqemu%d", unit); ++ if (*dev != NULL) { ++ dev_ref(*dev); ++ (*dev)->si_flags |= SI_CHEAPCLONE; ++ } ++ } ++} ++#endif ++ ++static void kqemu_destroy(struct kqemu_instance *ks) ++{ ++ struct cdev *dev = ks->kqemu_dev; ++ ++ if (ks->state) { ++ kqemu_delete(ks->state); ++ ks->state = NULL; ++ } ++ ++ free(ks, M_KQEMU); ++ dev->si_drv1 = NULL; ++#if __FreeBSD_version >= 500000 ++ TAILQ_REMOVE(&kqemuhead, ks, kqemu_ent); ++ destroy_dev(dev); ++#endif ++ --kqemu_ref_count; ++} + + /* ARGSUSED */ + static int ++#if __FreeBSD_version < 500000 ++kqemu_open(dev_t dev, int flags, int fmt __unused, struct proc *p) ++{ ++#else + kqemu_open(struct cdev *dev, int flags, int fmt __unused, + struct thread *td) + { ++ struct proc *p = td->td_proc; ++#endif + struct kqemu_instance *ks; ++ ++ if (dev->si_drv1 || kqemu_ref_count >= KQEMU_MAX_INSTANCES) ++ return(EBUSY); ++ ++ if ((flags & (FREAD|FWRITE)) == FREAD) ++ return(EPERM); ++ + ks = malloc(sizeof(struct kqemu_instance), M_KQEMU, M_WAITOK); + if (ks == NULL) { +- printf("malloc failed\n"); ++ kqemu_log("malloc failed\n"); + return ENOMEM; + } +- ks->state = NULL; ++ memset(ks, 0, sizeof *ks); ++#if __FreeBSD_version >= 500000 ++ ks->kqemu_dev = dev; ++ TAILQ_INSERT_TAIL(&kqemuhead, ks, kqemu_ent); ++#endif ++ kqemu_ref_count++; ++ + dev->si_drv1 = ks; ++ if (kqemu_debug > 0) ++ kqemu_log("opened by pid=%d\n", p->p_pid); + return 0; + } + + /* ARGSUSED */ + static int ++#if __FreeBSD_version < 500000 ++kqemu_ioctl(dev_t dev, u_long cmd, caddr_t addr, ++ int flags __unused, struct proc *p) ++#else + kqemu_ioctl(struct cdev *dev, u_long cmd, caddr_t addr, + int flags __unused, struct thread *td) ++#endif + { + int error = 0; + int ret; +@@ -233,8 +380,9 @@ + break; + } + d1 = *(struct kqemu_init *)addr; +- printf("ram_base=%p ram_size=%ld\n", d1.ram_base, d1.ram_size); +- s = kqemu_init(d, 16000); ++ if (kqemu_debug > 0) ++ kqemu_log("ram_base=%p ram_size=%ld\n", d1.ram_base, d1.ram_size); ++ s = kqemu_init(d, max_locked_pages); + if (s == NULL) { + error = ENOMEM; + break; +@@ -250,9 +398,16 @@ + } + ctx = kqemu_get_cpu_state(s); + *ctx = *(struct kqemu_cpu_state *)addr; ++#if __FreeBSD_version >= 500000 + DROP_GIANT(); ++#endif + ret = kqemu_exec(s); ++#if __FreeBSD_version >= 500000 + PICKUP_GIANT(); ++ td->td_retval[0] = ret; ++#else ++ p->p_retval[0] = ret; ++#endif + *(struct kqemu_cpu_state *)addr = *ctx; + break; + } +@@ -267,10 +422,22 @@ + + /* ARGSUSED */ + static int ++#if __FreeBSD_version < 500000 ++kqemu_close(dev_t dev, int flags, int fmt __unused, struct proc *p) ++{ ++#else + kqemu_close(struct cdev *dev __unused, int flags, int fmt __unused, + struct thread *td) + { +- return 0; ++ struct proc *p = td->td_proc; ++#endif ++ struct kqemu_instance *ks = (struct kqemu_instance *) dev->si_drv1; ++ ++ kqemu_destroy(ks); ++ ++ if (kqemu_debug > 0) ++ kqemu_log("closed by pid=%d\n", p->p_pid); ++ return 0; + } + + /* ARGSUSED */ +@@ -278,15 +445,55 @@ + kqemu_modevent(module_t mod __unused, int type, void *data __unused) + { + int error = 0; ++#if __FreeBSD_version < 500000 ++ int rc; ++#else ++ struct kqemu_instance *ks; ++#endif + + switch (type) { + case MOD_LOAD: + printf("kqemu version 0x%08x\n", KQEMU_VERSION); ++ max_locked_pages = physmem / (2 * KQEMU_MAX_INSTANCES); ++ if (max_locked_pages > 32768) ++ max_locked_pages = 32768; ++#if __FreeBSD_version < 500000 ++ if ((rc = cdevsw_add(&kqemu_cdevsw))) { ++ kqemu_log("error registering cdevsw, rc=%d\n", rc); ++ error = ENOENT; ++ break; ++ } + kqemu_dev = make_dev(&kqemu_cdevsw, 0, +- UID_ROOT, GID_WHEEL, 0666, "kqemu"); ++ UID_ROOT, GID_WHEEL, 0660, "kqemu"); ++#else ++ clone_setup(&kqemuclones); ++ clonetag = EVENTHANDLER_REGISTER(dev_clone, kqemu_clone, 0, 1000); ++ if (!clonetag) { ++ error = ENOMEM; ++ break; ++ } ++#endif ++ kqemu_log("KQEMU installed, max_instances=%d max_locked_mem=%dkB.\n", ++ KQEMU_MAX_INSTANCES, max_locked_pages * 4); ++ ++ kqemu_ref_count = 0; + break; + case MOD_UNLOAD: ++ if (kqemu_ref_count > 0) { ++ error = EBUSY; ++ break; ++ } ++#if __FreeBSD_version < 500000 + destroy_dev(kqemu_dev); ++ if ((rc = cdevsw_remove(&kqemu_cdevsw))) ++ kqemu_log("error unregistering, rc=%d\n", rc); ++#else ++ EVENTHANDLER_DEREGISTER(dev_clone, clonetag); ++ while ((ks = TAILQ_FIRST(&kqemuhead)) != NULL) { ++ kqemu_destroy(ks); ++ } ++ clone_cleanup(&kqemuclones); ++#endif + break; + case MOD_SHUTDOWN: + break; Index: files/patch-libmath2 @@ -0,0 +1,67 @@ +Index: qemu/bsd/Makefile +@@ -16,7 +16,8 @@ + ${MACHINE_ARCH}/s_rintl.c \ + ${MACHINE_ARCH}/s_round.c \ + ${MACHINE_ARCH}/s_sinl.S \ +- ${MACHINE_ARCH}/s_tanl.S ++ ${MACHINE_ARCH}/s_tanl.S \ ++ ${MACHINE_ARCH}/s_ldexpl.c + + OBJS= ${SRCS:R:S/$/.o/} + +Index: qemu/bsd/i386/s_ldexpl.c +@@ -0,0 +1,21 @@ ++#include ++#include ++#include ++ ++long double __ldexpl(long double x, int expn) ++{ ++ long double res; ++ if (!isfinite (x) || x == 0.0L) ++ return x; ++ ++ __asm__ ("fscale" ++ : "=t" (res) ++ : "0" (x), "u" ((long double) expn)); ++ ++ if (!isfinite (res) || res == 0.0L) ++ errno = ERANGE; ++ ++ return res; ++} ++ ++weak_alias(__ldexpl,ldexpl) +Index: qemu/bsd/amd64/s_ldexpl.c +@@ -0,0 +1,21 @@ ++#include ++#include ++#include ++ ++long double __ldexpl(long double x, int expn) ++{ ++ long double res; ++ if (!isfinite (x) || x == 0.0L) ++ return x; ++ ++ __asm__ ("fscale" ++ : "=t" (res) ++ : "0" (x), "u" ((long double) expn)); ++ ++ if (!isfinite (res) || res == 0.0L) ++ errno = ERANGE; ++ ++ return res; ++} ++ ++weak_alias(__ldexpl,ldexpl) +Index: qemu/target-i386/helper.c +@@ -2886,6 +2886,8 @@ + ST0 = floatx_round_to_int(ST0, &env->fp_status); + } + ++long double ldexpl(long double, int); ++ + void helper_fscale(void) + { + ST0 = ldexp (ST0, (int)(ST1)); Index: files/patch-vl.c @@ -0,0 +1,21 @@ +Index: qemu/vl.c +@@ -40,6 +40,10 @@ + #include + #include + #include ++#ifdef __FreeBSD__ ++#include ++#include ++#endif + #ifdef _BSD + #include + #ifndef __APPLE__ +@@ -1280,7 +1284,7 @@ + return chr; + } + +-#if defined(__linux__) ++#if defined(__linux__) || defined(__FreeBSD__) + CharDriverState *qemu_chr_open_pty(void) + { + char slave_name[1024]; From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 19:59:00 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 8359016A41F; Tue, 6 Sep 2005 19:59:00 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id C850C43D46; Tue, 6 Sep 2005 19:58:56 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.13.4/8.13.4/Debian-3) with ESMTP id j86Jwsr1023827; Tue, 6 Sep 2005 21:58:54 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id j86Jwsa1023825; Tue, 6 Sep 2005 21:58:54 +0200 Received: from saturn.kn-bremen.de (localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.1/8.13.1) with ESMTP id j86JsnA3010555; Tue, 6 Sep 2005 21:54:49 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.1/8.13.1/Submit) id j86Jsnko010554; Tue, 6 Sep 2005 21:54:49 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Tue, 6 Sep 2005 21:54:49 +0200 To: qemu-devel@nongnu.org, freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org Message-ID: <20050906195449.GA10388@saturn.kn-bremen.de> Mail-Followup-To: qemu-devel@nongnu.org, freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org References: <20050906190753.GA8560@saturn.kn-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050906190753.GA8560@saturn.kn-bremen.de> User-Agent: Mutt/1.4.2.1i Cc: Subject: oops! (was: FreeBSD qemu port update - some success with kqemu/amd64 :) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2005 19:59:00 -0000 Jung-uk Kim just made me aware of a device cloning change which requires a patch to the kqemu wrapper for __FreeBSD_version >= 600034. So here is a new port update: Removed files: files/BSDmakefile files/kmod_bsd.c New files: files/kqemu-freebsd-patch files/patch-libmath2 files/patch-vl.c Index: Makefile =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/Makefile,v retrieving revision 1.27 diff -u -r1.27 Makefile --- Makefile 19 Jul 2005 06:06:56 -0000 1.27 +++ Makefile 6 Sep 2005 18:02:11 -0000 @@ -6,12 +6,11 @@ # PORTNAME= qemu -PORTVERSION= 0.7.0s.20050717 +PORTVERSION= 0.7.2 CATEGORIES= emulators MASTER_SITES= http://www.qemu.org/ \ http://people.fruitsalad.org/nox/qemu/ \ http://dad-answers.com/qemu/ -DISTNAME= ${PORTNAME}-snapshot-2005-07-17_23 EXTRACT_ONLY= ${DISTNAME}${EXTRACT_SUFX} MAINTAINER= nox@jelal.kn-bremen.de @@ -23,12 +22,12 @@ .endif .if defined(WITH_KQEMU) -DISTKQEMU= kqemu-0.6.2-1.tar.gz +DISTKQEMU= kqemu-0.7.2.tar.gz DISTFILES= ${EXTRACT_ONLY} ${DISTKQEMU} +EXTRA_PATCHES= ${FILESDIR}/kqemu-freebsd-patch .endif HAS_CONFIGURE= yes -USE_BZIP2= yes USE_GMAKE= yes USE_GETOPT_LONG= yes USE_SDL= sdl @@ -40,9 +39,11 @@ ONLY_FOR_ARCHS= amd64 i386 .if defined(WITH_KQEMU) NO_PACKAGE= Depends on kernel, and module not redistributable +CONFIGURE_ARGS+= --enable-kqemu PLIST_SUB= WITH_KQEMU="" PLIST_SUB+= KMODDIR=${KMODDIR} .else +CONFIGURE_ARGS+= --disable-kqemu PLIST_SUB= WITH_KQEMU="@comment " .endif @@ -52,7 +53,7 @@ .if ${ARCH} == "amd64" ARCH= x86_64 -.if ${OSVERSION} >= 502126 +.if ${OSVERSION} >= 502126 && ${OSVERSION} <= 600029 BUILD_DEPENDS+= gcc34:${PORTSDIR}/lang/gcc34 GCCVERSION= 030402 CC= gcc34 @@ -63,16 +64,12 @@ USE_GCC= 3.4 .endif -.if defined(WITH_KQEMU) && ${ARCH} != "i386" -IGNORE= kqemu only supported on i386 -.endif - .if defined(WITH_KQEMU) && !exists(${SRC_BASE}/sys/Makefile) IGNORE= kqemu requires kernel source to be installed .endif pre-everything:: -.if !defined(WITH_KQEMU) && ${ARCH} == "i386" +.if !defined(WITH_KQEMU) @${ECHO_MSG} "Notice: you can build qemu with the (alpha!) kqemu accelerator kernel module" @${ECHO_MSG} "by defining WITH_KQEMU." .endif @@ -85,7 +82,7 @@ .if defined(WITH_KQEMU) post-extract: @cd ${WRKSRC} && ${TAR} xfz ${_DISTDIR}/${DISTKQEMU} - @${CP} ${FILESDIR}/BSDmakefile ${FILESDIR}/kmod_bsd.c ${WRKSRC}/kqemu + @${LN} -s Makefile.freebsd ${WRKSRC}/kqemu/BSDmakefile .endif pre-patch: Index: distinfo =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/distinfo,v retrieving revision 1.20 diff -u -r1.20 distinfo --- distinfo 19 Jul 2005 06:06:56 -0000 1.20 +++ distinfo 6 Sep 2005 18:02:22 -0000 @@ -1,4 +1,4 @@ -MD5 (qemu-snapshot-2005-07-17_23.tar.bz2) = 5d21295c1f328ea00de19a54715ee7c3 -SIZE (qemu-snapshot-2005-07-17_23.tar.bz2) = 1114748 -MD5 (kqemu-0.6.2-1.tar.gz) = c6bb3b40fb3d526d731eb0f1f9dee7ee -SIZE (kqemu-0.6.2-1.tar.gz) = 21002 +MD5 (qemu-0.7.2.tar.gz) = 7d69dd96edf7ae5298a9a7283a0e9fb8 +SIZE (qemu-0.7.2.tar.gz) = 1341993 +MD5 (kqemu-0.7.2.tar.gz) = 02cfdecda90458d6393781496ec6b48b +SIZE (kqemu-0.7.2.tar.gz) = 79314 Index: pkg-message =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/pkg-message,v retrieving revision 1.8 diff -u -r1.8 pkg-message --- pkg-message 1 May 2005 07:39:10 -0000 1.8 +++ pkg-message 6 Sep 2005 18:23:22 -0000 @@ -1,6 +1,9 @@ ==== FreeBSD host notes: - needs to run as root in order to use /dev/tap* networking (why?) +(actually RELENG_6 and above now has a sysctl net.link.tap.user_open +to allow users to use it too. don't forget to adjust device node +permissions in /etc/devfs.rules.) - slirp (usermode networking) is fixed now in cvs, on FreeSBIE 1.0 guests you still have to manually do: echo nameserver 10.0.2.3 >/etc/resolv.conf @@ -18,4 +21,9 @@ ioctl.) - the -smb option (smb-export local dir to guest) needs the net/samba port/package installed in addition to qemu. +- RELENG_6 and up guests often crash while accessing the emulated cdrom +(see kern/84102, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84102), +using a kernel without PREEMPTION has been reported to fix this problem. +(or do an ftp install instead of installing from the emulated cdrom, and +then make a new kernel.) ==== Index: files/patch-fbsd =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/files/patch-fbsd,v retrieving revision 1.2 diff -u -r1.2 patch-fbsd --- files/patch-fbsd 5 May 2005 12:41:10 -0000 1.2 +++ files/patch-fbsd 11 Aug 2005 16:38:42 -0000 @@ -13,7 +13,7 @@ $(MAKE) -C kqemu -f Makefile.winnt else - $(MAKE) -C kqemu -+ cd kqemu && $(BSD_MAKE) ++ ( cd kqemu && $(BSD_MAKE) ) endif endif Index: files/kqemu-freebsd-patch @@ -0,0 +1,506 @@ +Index: qemu/kqemu/Makefile.freebsd +@@ -1,9 +1,13 @@ ++# $Id: Makefile.freebsd,v 1.1 2005/04/17 17:21:31 bellard Exp $ + KMOD= kqemu + SRCS= kqemu-freebsd.c + .if ${MACHINE_ARCH} == "i386" + OBJS= kqemu-mod-i386.o + .elif ${MACHINE_ARCH} == "amd64" + OBJS= kqemu-mod-x86_64.o ++.endif ++.if ${OSVERSION} >= 500000 ++CC= cc + .endif + WERROR= + +Index: qemu/kqemu/kqemu-freebsd.c +@@ -3,20 +3,33 @@ + #include + #include + #include ++#include ++#include + #include + #include + #include + #include + #include ++#include ++#if __FreeBSD_version >= 500000 + #include ++#endif + #include + #include ++#include ++#include ++#if __FreeBSD_version < 500000 ++#include ++#endif ++ + #include + #include + #include + #include + #include + #include ++#include ++ + #include + #include + +@@ -25,10 +38,14 @@ + MALLOC_DECLARE(M_KQEMU); + MALLOC_DEFINE(M_KQEMU, "kqemu", "kqemu buffers"); + ++int kqemu_debug; ++SYSCTL_INT(_debug, OID_AUTO, kqemu_debug, CTLFLAG_RW, &kqemu_debug, 0, ++ "kqemu debug flag"); ++ + #define USER_BASE 0x1000 + + /* lock the page at virtual address 'user_addr' and return its +- physical page index. Return -1 if error */ ++ physical page index. Return NULL if error */ + struct kqemu_user_page *CDECL kqemu_lock_user_page(unsigned long *ppage_index, + unsigned long user_addr) + { +@@ -37,14 +54,18 @@ + vm_paddr_t pa = 0; + int ret; + pmap_t pmap; ++#if __FreeBSD_version >= 500000 + ret = vm_map_wire(&vm->vm_map, va, va+PAGE_SIZE, VM_MAP_WIRE_USER); ++#else ++ ret = vm_map_user_pageable(&vm->vm_map, va, va+PAGE_SIZE, FALSE); ++#endif + if (ret != KERN_SUCCESS) { +- printf("kqemu_lock_user_page(%08lx) failed, ret=%d\n", user_addr, ret); ++ kqemu_log("kqemu_lock_user_page(%08lx) failed, ret=%d\n", user_addr, ret); + return NULL; + } + pmap = vm_map_pmap(&vm->vm_map); + pa = pmap_extract(pmap, va); +- // printf("kqemu_lock_user_page(%08lx) va=%08x pa=%08x\n", user_addr, va, pa); ++ // kqemu_log("kqemu_lock_user_page(%08lx) va=%08x pa=%08x\n", user_addr, va, pa); + *ppage_index = pa >> PAGE_SHIFT; + return (struct kqemu_user_page *)va; + } +@@ -54,12 +75,16 @@ + struct vmspace *vm = curproc->p_vmspace; + vm_offset_t va; + int ret; +- // printf("kqemu_unlock_user_page(%08lx)\n", page_index); ++ // kqemu_log("kqemu_unlock_user_page(%08lx)\n", page_index); + va = (vm_offset_t)page; ++#if __FreeBSD_version >= 500000 + ret = vm_map_unwire(&vm->vm_map, va, va+PAGE_SIZE, VM_MAP_WIRE_USER); ++#else ++ ret = vm_map_user_pageable(&vm->vm_map, va, va+PAGE_SIZE, TRUE); ++#endif + #if 0 + if (ret != KERN_SUCCESS) { +- printf("kqemu_unlock_user_page(%08lx) failed, ret=%d\n", page_index, ret); ++ kqemu_log("kqemu_unlock_user_page(%08lx) failed, ret=%d\n", page_index, ret); + } + #endif + } +@@ -76,20 +101,21 @@ + + va = kmem_alloc(kernel_map, PAGE_SIZE); + if (va == 0) { +- printf("kqemu_alloc_zeroed_page: NULL\n"); +- return -1; ++ kqemu_log("kqemu_alloc_zeroed_page: NULL\n"); ++ return NULL; + } + pmap = vm_map_pmap(kernel_map); + pa = pmap_extract(pmap, va); +- // printf("kqemu_alloc_zeroed_page: %08x\n", pa); ++ // kqemu_log("kqemu_alloc_zeroed_page: %08x\n", pa); + *ppage_index = pa >> PAGE_SHIFT; + return (struct kqemu_page *)va; + } + + void CDECL kqemu_free_page(struct kqemu_page *page) + { +- // printf("kqemu_free_page(%08lx)\n", page_index); +- /* XXX: do it */ ++ if (kqemu_debug > 0) ++ kqemu_log("kqemu_free_page(%p)\n", page); ++ kmem_free(kernel_map, (vm_offset_t) page, PAGE_SIZE); + } + + /* return kernel address of the physical page page_index */ +@@ -103,42 +129,29 @@ + GB of physical memory */ + void * CDECL kqemu_vmalloc(unsigned int size) + { +- struct vmspace *vm = curproc->p_vmspace; +- vm_offset_t va = USER_BASE; +- int rv; +- if (size % PAGE_SIZE != 0) { +- printf("kqemu_vmalloc(%d) not a multiple of page size\n", size); +- return NULL; +- } +- rv = vm_map_find(&vm->vm_map, NULL, 0, &va, size, 1, +- VM_PROT_ALL, VM_PROT_ALL, 0); +- if (rv != KERN_SUCCESS) { +- printf("kqemu_vmalloc(%d) failed rv=%d\n", size, rv); +- return NULL; +- } +- printf("kqemu_vmalloc(%d): %08x\n", size, va); +- return (void *)va; ++ void *ptr = malloc(size, M_KQEMU, M_WAITOK); ++ if (kqemu_debug > 0) ++ kqemu_log("kqemu_vmalloc(%d): %p\n", size, ptr); ++ return ptr; + } + + void CDECL kqemu_vfree(void *ptr) + { +- printf("kqemu_vfree(%p)\n", ptr); ++ if (kqemu_debug > 0) ++ kqemu_log("kqemu_vfree(%p)\n", ptr); ++ free(ptr, M_KQEMU); + } + + /* return the physical page index for a given virtual page */ + unsigned long CDECL kqemu_vmalloc_to_phys(const void *vaddr) + { +- struct vmspace *vm = curproc->p_vmspace; +- vm_paddr_t pa; +- pmap_t pmap; +- +- pmap = vm_map_pmap(&vm->vm_map); +- pa = pmap_extract(pmap, (vm_offset_t)vaddr); ++ vm_paddr_t pa = vtophys(vaddr); + if (pa == 0) { +- printf("kqemu_vmalloc_to_phys(%p)->error\n", vaddr); ++ kqemu_log("kqemu_vmalloc_to_phys(%p)->error\n", vaddr); + return -1; + } +- printf("kqemu_vmalloc_to_phys(%p)->%08x\n", vaddr, pa); ++ if (kqemu_debug > 0) ++ kqemu_log("kqemu_vmalloc_to_phys(%p)->%08x\n", vaddr, pa); + return pa >> PAGE_SHIFT; + } + +@@ -154,16 +167,48 @@ + { + } + ++#if __FreeBSD_version < 500000 ++static int ++curpriority_cmp(struct proc *p) ++{ ++ int c_class, p_class; ++ ++ c_class = RTP_PRIO_BASE(curproc->p_rtprio.type); ++ p_class = RTP_PRIO_BASE(p->p_rtprio.type); ++ if (p_class != c_class) ++ return (p_class - c_class); ++ if (p_class == RTP_PRIO_NORMAL) ++ return (((int)p->p_priority - (int)curpriority) / PPQ); ++ return ((int)p->p_rtprio.prio - (int)curproc->p_rtprio.prio); ++} ++ + /* return TRUE if a signal is pending (i.e. the guest must stop + execution) */ + int CDECL kqemu_schedule(void) + { +- // printf("kqemu_schedule\n"); ++ struct proc *p = curproc; ++ if (curpriority_cmp(p) > 0) { ++ int s = splhigh(); ++ p->p_priority = MAXPRI; ++ setrunqueue(p); ++ p->p_stats->p_ru.ru_nvcsw++; ++ mi_switch(); ++ splx(s); ++ } ++ return issignal(curproc) != 0; ++} ++#else ++/* return TRUE if a signal is pending (i.e. the guest must stop ++ execution) */ ++int CDECL kqemu_schedule(void) ++{ ++ // kqemu_log("kqemu_schedule\n"); + mtx_lock_spin(&sched_lock); + mi_switch(SW_VOL, NULL); + mtx_unlock_spin(&sched_lock); + return SIGPENDING(curthread); + } ++#endif + + static char log_buf[4096]; + +@@ -176,47 +221,154 @@ + va_end(ap); + } + ++#define KQEMU_MAX_INSTANCES 4 ++ + struct kqemu_instance { ++#if __FreeBSD_version >= 500000 ++ TAILQ_ENTRY(kqemu_instance) kqemu_ent; ++ struct cdev *kqemu_dev; ++#endif + // struct semaphore sem; + struct kqemu_state *state; + }; + ++static int kqemu_ref_count = 0; ++static int max_locked_pages; ++ ++#if __FreeBSD_version < 500000 ++static dev_t kqemu_dev; ++#else ++static struct clonedevs *kqemuclones; ++static TAILQ_HEAD(,kqemu_instance) kqemuhead = TAILQ_HEAD_INITIALIZER(kqemuhead); ++static eventhandler_tag clonetag; ++#endif ++ + static d_close_t kqemu_close; + static d_open_t kqemu_open; + static d_ioctl_t kqemu_ioctl; + + static struct cdevsw kqemu_cdevsw = { ++#if __FreeBSD_version < 500000 ++ /* open */ kqemu_open, ++ /* close */ kqemu_close, ++ /* read */ noread, ++ /* write */ nowrite, ++ /* ioctl */ kqemu_ioctl, ++ /* poll */ nopoll, ++ /* mmap */ nommap, ++ /* strategy */ nostrategy, ++ /* name */ "kqemu", ++ /* maj */ KQEMU_MAJOR, ++ /* dump */ nodump, ++ /* psize */ nopsize, ++ /* flags */ 0, ++ /* bmaj */ -1 ++#else + .d_version = D_VERSION, + .d_flags = D_NEEDGIANT, + .d_open = kqemu_open, + .d_ioctl = kqemu_ioctl, + .d_close = kqemu_close, + .d_name = "kqemu" ++#endif + }; + +-/* For use with make_dev(9)/destroy_dev(9). */ +-static struct cdev *kqemu_dev; ++#if __FreeBSD_version >= 500000 ++static void ++#if __FreeBSD_version >= 600034 ++kqemu_clone(void *arg, struct ucred *cred, char *name, int namelen, ++struct cdev **dev) ++#else ++kqemu_clone(void *arg, char *name, int namelen, struct cdev **dev) ++#endif ++{ ++ int unit, r; ++ if (*dev != NULL) ++ return; ++ ++ if (strcmp(name, "kqemu") == 0) ++ unit = -1; ++ else if (dev_stdclone(name, NULL, "kqemu", &unit) != 1) ++ return; /* Bad name */ ++ if (unit != -1 && unit > KQEMU_MAX_INSTANCES) ++ return; ++ ++ r = clone_create(&kqemuclones, &kqemu_cdevsw, &unit, dev, 0); ++ if (r) { ++ *dev = make_dev(&kqemu_cdevsw, unit2minor(unit), ++ UID_ROOT, GID_WHEEL, 0660, "kqemu%d", unit); ++ if (*dev != NULL) { ++ dev_ref(*dev); ++ (*dev)->si_flags |= SI_CHEAPCLONE; ++ } ++ } ++} ++#endif ++ ++static void kqemu_destroy(struct kqemu_instance *ks) ++{ ++ struct cdev *dev = ks->kqemu_dev; ++ ++ if (ks->state) { ++ kqemu_delete(ks->state); ++ ks->state = NULL; ++ } ++ ++ free(ks, M_KQEMU); ++ dev->si_drv1 = NULL; ++#if __FreeBSD_version >= 500000 ++ TAILQ_REMOVE(&kqemuhead, ks, kqemu_ent); ++ destroy_dev(dev); ++#endif ++ --kqemu_ref_count; ++} + + /* ARGSUSED */ + static int ++#if __FreeBSD_version < 500000 ++kqemu_open(dev_t dev, int flags, int fmt __unused, struct proc *p) ++{ ++#else + kqemu_open(struct cdev *dev, int flags, int fmt __unused, + struct thread *td) + { ++ struct proc *p = td->td_proc; ++#endif + struct kqemu_instance *ks; ++ ++ if (dev->si_drv1 || kqemu_ref_count >= KQEMU_MAX_INSTANCES) ++ return(EBUSY); ++ ++ if ((flags & (FREAD|FWRITE)) == FREAD) ++ return(EPERM); ++ + ks = malloc(sizeof(struct kqemu_instance), M_KQEMU, M_WAITOK); + if (ks == NULL) { +- printf("malloc failed\n"); ++ kqemu_log("malloc failed\n"); + return ENOMEM; + } +- ks->state = NULL; ++ memset(ks, 0, sizeof *ks); ++#if __FreeBSD_version >= 500000 ++ ks->kqemu_dev = dev; ++ TAILQ_INSERT_TAIL(&kqemuhead, ks, kqemu_ent); ++#endif ++ kqemu_ref_count++; ++ + dev->si_drv1 = ks; ++ if (kqemu_debug > 0) ++ kqemu_log("opened by pid=%d\n", p->p_pid); + return 0; + } + + /* ARGSUSED */ + static int ++#if __FreeBSD_version < 500000 ++kqemu_ioctl(dev_t dev, u_long cmd, caddr_t addr, ++ int flags __unused, struct proc *p) ++#else + kqemu_ioctl(struct cdev *dev, u_long cmd, caddr_t addr, + int flags __unused, struct thread *td) ++#endif + { + int error = 0; + int ret; +@@ -231,8 +383,9 @@ + break; + } + d1 = *(struct kqemu_init *)addr; +- printf("ram_base=%p ram_size=%ld\n", d1.ram_base, d1.ram_size); +- s = kqemu_init(d, 16000); ++ if (kqemu_debug > 0) ++ kqemu_log("ram_base=%p ram_size=%ld\n", d1.ram_base, d1.ram_size); ++ s = kqemu_init(d, max_locked_pages); + if (s == NULL) { + error = ENOMEM; + break; +@@ -248,9 +401,16 @@ + } + ctx = kqemu_get_cpu_state(s); + *ctx = *(struct kqemu_cpu_state *)addr; ++#if __FreeBSD_version >= 500000 + DROP_GIANT(); ++#endif + ret = kqemu_exec(s); ++#if __FreeBSD_version >= 500000 + PICKUP_GIANT(); ++ td->td_retval[0] = ret; ++#else ++ p->p_retval[0] = ret; ++#endif + *(struct kqemu_cpu_state *)addr = *ctx; + break; + } +@@ -265,10 +425,22 @@ + + /* ARGSUSED */ + static int ++#if __FreeBSD_version < 500000 ++kqemu_close(dev_t dev, int flags, int fmt __unused, struct proc *p) ++{ ++#else + kqemu_close(struct cdev *dev __unused, int flags, int fmt __unused, + struct thread *td) + { +- return 0; ++ struct proc *p = td->td_proc; ++#endif ++ struct kqemu_instance *ks = (struct kqemu_instance *) dev->si_drv1; ++ ++ kqemu_destroy(ks); ++ ++ if (kqemu_debug > 0) ++ kqemu_log("closed by pid=%d\n", p->p_pid); ++ return 0; + } + + /* ARGSUSED */ +@@ -276,15 +448,55 @@ + kqemu_modevent(module_t mod __unused, int type, void *data __unused) + { + int error = 0; ++#if __FreeBSD_version < 500000 ++ int rc; ++#else ++ struct kqemu_instance *ks; ++#endif + + switch (type) { + case MOD_LOAD: + printf("kqemu version 0x%08x\n", KQEMU_VERSION); ++ max_locked_pages = physmem / (2 * KQEMU_MAX_INSTANCES); ++ if (max_locked_pages > 32768) ++ max_locked_pages = 32768; ++#if __FreeBSD_version < 500000 ++ if ((rc = cdevsw_add(&kqemu_cdevsw))) { ++ kqemu_log("error registering cdevsw, rc=%d\n", rc); ++ error = ENOENT; ++ break; ++ } + kqemu_dev = make_dev(&kqemu_cdevsw, 0, +- UID_ROOT, GID_WHEEL, 0666, "kqemu"); ++ UID_ROOT, GID_WHEEL, 0660, "kqemu"); ++#else ++ clone_setup(&kqemuclones); ++ clonetag = EVENTHANDLER_REGISTER(dev_clone, kqemu_clone, 0, 1000); ++ if (!clonetag) { ++ error = ENOMEM; ++ break; ++ } ++#endif ++ kqemu_log("KQEMU installed, max_instances=%d max_locked_mem=%dkB.\n", ++ KQEMU_MAX_INSTANCES, max_locked_pages * 4); ++ ++ kqemu_ref_count = 0; + break; + case MOD_UNLOAD: ++ if (kqemu_ref_count > 0) { ++ error = EBUSY; ++ break; ++ } ++#if __FreeBSD_version < 500000 + destroy_dev(kqemu_dev); ++ if ((rc = cdevsw_remove(&kqemu_cdevsw))) ++ kqemu_log("error unregistering, rc=%d\n", rc); ++#else ++ EVENTHANDLER_DEREGISTER(dev_clone, clonetag); ++ while ((ks = TAILQ_FIRST(&kqemuhead)) != NULL) { ++ kqemu_destroy(ks); ++ } ++ clone_cleanup(&kqemuclones); ++#endif + break; + case MOD_SHUTDOWN: + break; Index: files/patch-libmath2 @@ -0,0 +1,67 @@ +Index: qemu/bsd/Makefile +@@ -16,7 +16,8 @@ + ${MACHINE_ARCH}/s_rintl.c \ + ${MACHINE_ARCH}/s_round.c \ + ${MACHINE_ARCH}/s_sinl.S \ +- ${MACHINE_ARCH}/s_tanl.S ++ ${MACHINE_ARCH}/s_tanl.S \ ++ ${MACHINE_ARCH}/s_ldexpl.c + + OBJS= ${SRCS:R:S/$/.o/} + +Index: qemu/bsd/i386/s_ldexpl.c +@@ -0,0 +1,21 @@ ++#include ++#include ++#include ++ ++long double __ldexpl(long double x, int expn) ++{ ++ long double res; ++ if (!isfinite (x) || x == 0.0L) ++ return x; ++ ++ __asm__ ("fscale" ++ : "=t" (res) ++ : "0" (x), "u" ((long double) expn)); ++ ++ if (!isfinite (res) || res == 0.0L) ++ errno = ERANGE; ++ ++ return res; ++} ++ ++weak_alias(__ldexpl,ldexpl) +Index: qemu/bsd/amd64/s_ldexpl.c +@@ -0,0 +1,21 @@ ++#include ++#include ++#include ++ ++long double __ldexpl(long double x, int expn) ++{ ++ long double res; ++ if (!isfinite (x) || x == 0.0L) ++ return x; ++ ++ __asm__ ("fscale" ++ : "=t" (res) ++ : "0" (x), "u" ((long double) expn)); ++ ++ if (!isfinite (res) || res == 0.0L) ++ errno = ERANGE; ++ ++ return res; ++} ++ ++weak_alias(__ldexpl,ldexpl) +Index: qemu/target-i386/helper.c +@@ -2886,6 +2886,8 @@ + ST0 = floatx_round_to_int(ST0, &env->fp_status); + } + ++long double ldexpl(long double, int); ++ + void helper_fscale(void) + { + ST0 = ldexp (ST0, (int)(ST1)); Index: files/patch-vl.c @@ -0,0 +1,21 @@ +Index: qemu/vl.c +@@ -40,6 +40,10 @@ + #include + #include + #include ++#ifdef __FreeBSD__ ++#include ++#include ++#endif + #ifdef _BSD + #include + #ifndef __APPLE__ +@@ -1280,7 +1284,7 @@ + return chr; + } + +-#if defined(__linux__) ++#if defined(__linux__) || defined(__FreeBSD__) + CharDriverState *qemu_chr_open_pty(void) + { + char slave_name[1024]; From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 20:09: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 36CB416A41F for ; Tue, 6 Sep 2005 20:09:51 +0000 (GMT) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2C2543D48 for ; Tue, 6 Sep 2005 20:09:50 +0000 (GMT) (envelope-from bra@fsn.hu) Received: from localhost (localhost [127.0.0.1]) by people.fsn.hu (Postfix) with ESMTP id F191D84418 for ; Tue, 6 Sep 2005 22:09:45 +0200 (CEST) Received: from people.fsn.hu ([127.0.0.1]) by localhost (people.fsn.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 71119-04 for ; Tue, 6 Sep 2005 22:09:36 +0200 (CEST) Received: from [192.168.0.100] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 6BAE984408 for ; Tue, 6 Sep 2005 22:09:36 +0200 (CEST) Message-ID: <431DF77F.1010604@fsn.hu> Date: Tue, 06 Sep 2005 22:09:35 +0200 From: Nagy Attila User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: hu, en-us MIME-Version: 1.0 To: freebsd-amd64@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at fsn.hu Subject: Tyan S2892 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, 06 Sep 2005 20:09:51 -0000 Hello, I don't see any reports of Tyan S2892 on FreeBSD's AMD64 compatibility page, so I ask. Does anybody have any knowledge with this board? What I would like to know -besides the general problems, like usefulness, stability problems with a "normal" and some bigger memory setups, etc- is whether I could use an Areca 1260 (PCI Express) card or not. There were some posts last year about supporting PCI-E in 5-STABLE, but I don't know where we are in this manner now. Thanks. ps: http://www.tyan.com/products/html/thunderk8se_spec.html -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 371 3536 ISOs: http://www.fsn.hu/?f=download cell.: +3630 306 6758 From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 20:10: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 DC77416A41F; Tue, 6 Sep 2005 20:10:50 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7723543D46; Tue, 6 Sep 2005 20:10:47 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j86KFpLe066208; Tue, 6 Sep 2005 16:15:51 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-amd64@FreeBSD.org Date: Tue, 6 Sep 2005 16:10:22 -0400 User-Agent: KMail/1.6.2 References: <20050906190753.GA8560@saturn.kn-bremen.de> <20050906195449.GA10388@saturn.kn-bremen.de> In-Reply-To: <20050906195449.GA10388@saturn.kn-bremen.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <200509061610.24704.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.85.1/1066/Tue Sep 6 07:42:41 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-emulation@FreeBSD.org, Juergen Lock , qemu-devel@nongnu.org Subject: Re: oops! (was: FreeBSD qemu port update - some success with kqemu/amd64 :) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2005 20:10:51 -0000 On Tuesday 06 September 2005 03:54 pm, Juergen Lock wrote: > Jung-uk Kim just made me aware of a device cloning change which > requires a patch to the kqemu wrapper for __FreeBSD_version >= > 600034.  So here is a new port update: --- >8 --- SNIP!!! --- >8 --- It is working as advertised on FreeBSD/amd64 -CURRENT host now. :-) BTW, I just confirmed FreeBSD 6.0-BETA4 guest works when PREEMPTION option is removed from kernel configuration. Thanks for the update, Jung-uk Kim From owner-freebsd-amd64@FreeBSD.ORG Tue Sep 6 22:30:11 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 0F1D416A41F for ; Tue, 6 Sep 2005 22:30:11 +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 8450143D45 for ; Tue, 6 Sep 2005 22:30:10 +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 j86MUAt5074980 for ; Tue, 6 Sep 2005 22:30:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j86MUA32074978; Tue, 6 Sep 2005 22:30:10 GMT (envelope-from gnats) Resent-Date: Tue, 6 Sep 2005 22:30:10 GMT Resent-Message-Id: <200509062230.j86MUA32074978@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, "James O'Gorman" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB9FA16A41F for ; Tue, 6 Sep 2005 22:22:39 +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 76BE943D46 for ; Tue, 6 Sep 2005 22:22:39 +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 j86MMdPS007851 for ; Tue, 6 Sep 2005 22:22:39 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j86MMdiO007850; Tue, 6 Sep 2005 22:22:39 GMT (envelope-from nobody) Message-Id: <200509062222.j86MMdiO007850@www.freebsd.org> Date: Tue, 6 Sep 2005 22:22:39 GMT From: "James O'Gorman" To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/85812: "Rebooting..." on serial console appears garbled 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, 06 Sep 2005 22:30:11 -0000 >Number: 85812 >Category: amd64 >Synopsis: "Rebooting..." on serial console appears garbled >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: Tue Sep 06 22:30:09 GMT 2005 >Closed-Date: >Last-Modified: >Originator: James O'Gorman >Release: 6.0-BETA4 >Organization: >Environment: FreeBSD starbug.netinertia.co.uk 6.0-BETA4 FreeBSD 6.0-BETA4 #0: Tue Sep 6 22:33:12 BST 2005 root@starbug.netinertia.co.uk:/usr/obj/usr/src/sys/STARBUG amd64 >Description: When using a serial console on the amd64 version of 6.0-BETA, when executing a `shutdown -r now`, the text that should say "Rebooting..." appears garbled on the serial console. This does not happen on the i386 version of 6.0-BETA4 >How-To-Repeat: Install 6.0-BETA (any), amd64, enable serial console by running `echo -Dh > /boot.config` and reboot. When serial console has been verified as working, run a reboot or shutdown command and observe the serial console. >Fix: Unknown as yet... >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Wed Sep 7 01:47: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 C1EBB16A41F for ; Wed, 7 Sep 2005 01:47:02 +0000 (GMT) (envelope-from peter@wemm.org) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BE3943D45 for ; Wed, 7 Sep 2005 01:47:02 +0000 (GMT) (envelope-from peter@wemm.org) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 80A3F1976E; Tue, 6 Sep 2005 18:47:02 -0700 (PDT) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Tue, 6 Sep 2005 18:47:01 -0700 User-Agent: KMail/1.8.2 References: <4317CFF8.6030202@meijome.net> In-Reply-To: <4317CFF8.6030202@meijome.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509061847.01996.peter@wemm.org> Cc: Norberto Meijome Subject: Re: Curious : why does the booloader say i386 on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2005 01:47:02 -0000 On Thursday 01 September 2005 09:07 pm, Norberto Meijome wrote: > FreeBSD/i386 boot > > # sysctl -a | grep machine > hw.machine: amd64 > hw.machine_arch: amd64 > > # uname -rms > FreeBSD 6.0-BETA3 amd64 > > > Is it common code between i386 + amd64? is it just a label ? do I > have an old bootloader from a previous non-amd64 incantation > (possible, though I'm pretty sure I dd'ed the first few megs of all > drives before installing amd64...) The amd64 boot loader *is* the i386 boot loader. We have a common loader for both platforms. Yes, the FreeBSD/i386 loader can load and run an amd64 kernel right off the i386 cdrom etc. There was no benefit to be had by making a 64 bit loader. It really wasn't necessary and would just have been a whole lot of work for no good reason. For what its worth, the loader switches modes depending on which type of kernel is loaded. If you load a 64 bit kernel, then moments before starting it up, it creates a page table tree to replicate the kernel environment over the entire address space, the loader itself switches to 64 bit mode, and then jumps directly to the kernel at its native 64 bit address entry point. On i386, it jumps to the kernel in "flat" protected mode but at before-relocated address. The i386 kernel has to build a page table tree itself and deal with running at its non-relocated address by doing lots of work in assembler. Compare i386/locode.s with amd64/locore.S to see the benefit. Also see create_pagetables() in amd64/machdep.c - that code is in assembler on i386, but simple C on amd64. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Wed Sep 7 02:50:09 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 06A0016A41F for ; Wed, 7 Sep 2005 02:50:09 +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 EBB9443D46 for ; Wed, 7 Sep 2005 02:50: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 j872o76i005972 for ; Wed, 7 Sep 2005 02:50:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j872o7EF005971; Wed, 7 Sep 2005 02:50:07 GMT (envelope-from gnats) Resent-Date: Wed, 7 Sep 2005 02:50:07 GMT Resent-Message-Id: <200509070250.j872o7EF005971@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, NAKATA@FreeBSD.org, Maho Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4718116A41F for ; Wed, 7 Sep 2005 02:40:06 +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 EAD1843D46 for ; Wed, 7 Sep 2005 02:40:05 +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 j872e5CR009549 for ; Wed, 7 Sep 2005 02:40:05 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j872e5fk009548; Wed, 7 Sep 2005 02:40:05 GMT (envelope-from nobody) Message-Id: <200509070240.j872e5fk009548@www.freebsd.org> Date: Wed, 7 Sep 2005 02:40:05 GMT From: NAKATA@FreeBSD.org, Maho To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: amd64/85820: 1.5 times slower performance with SCHED_ULE than SCHED_4BSD 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, 07 Sep 2005 02:50:09 -0000 >Number: 85820 >Category: amd64 >Synopsis: 1.5 times slower performance with SCHED_ULE than SCHED_4BSD >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: Wed Sep 07 02:50:07 GMT 2005 >Closed-Date: >Last-Modified: >Originator: NAKATA, Maho >Release: FreeBSD/amd64 5.4-RELEASE >Organization: FreeBSD.org >Environment: FreeBSD ligeti.private.org 5.4-RELEASE-p5 FreeBSD 5.4-RELEASE-p5 #0: Thu Jul 28 09:34:57 JST 2005 maho@ligeti.private.org:/usr/src/sys/amd64/compile/MAHO amd64 >Description: I have noticed (last year) that SCHED_ULE is slower than SCHED_4BSD, and raised a PR. At that time it was not convincing because 5.3-RELEASE/amd64 was not stable enough with large amount of memory, etc. My recent 5.4-RELEASE/amd64 is extremely stable even with large amount of memory and high load, and I can say something definite. Someone who is interested in my e-mail, please test it. I also prepared statically linked binaries to reproduce my test easily, because this test uses ATLAS (math/atlas-devel) which is a really really pain to build. my conclusion in short: SCHED_ULE is slower than SCHED_4BSD by 1.5 times in FreeBSD 5.4-RELEASE/amd64. this means both SCHED_4BSD and SCHED_ULE are definitely SMP aware, but SCHED_ULE scheduling is not efficient for very large jobs. Whereas 4BSD is almost optimal. my opetron box: o Tyan S2885 Tiger K8W o Opteron 242x2 (1.6GHzx2) o Transcend 2Gx8 (total 16G) How to repeat: fetch http://people.freebsd.org/~maho/scheduler_amd64.tar.gz tar xvfz scheduler_amd64.tar.gz cd scheduler_amd64/ sysctl kern.sched.name ; /usr/bin/time ./xdinvtst_pt -N 7000 9000 200 My results: o 4BSD sysctl kern.sched.name ; /usr/bin/time ./xdinvtst_pt -N 7000 9000 200 kern.sched.name: 4BSD NREPS ORDER UPLO N LDA TIME MFLOP RESID ===== ===== ===== ===== ===== ======== ======== ============ 0 Col GE 7000 7000 157.028 4368.50 2.110725e-02 0 Col GE 7200 7200 168.527 4429.39 2.106386e-02 0 Col GE 7400 7400 185.014 4380.32 2.099199e-02 0 Col GE 7600 7600 198.622 4420.07 2.073756e-02 0 Col GE 7800 7800 214.284 4429.04 2.089531e-02 0 Col GE 8000 8000 232.126 4411.27 2.142018e-02 0 Col GE 8200 8200 255.809 4310.65 2.041516e-02 0 Col GE 8400 8400 265.088 4471.62 2.092699e-02 0 Col GE 8600 8600 285.403 4457.11 2.119786e-02 0 Col GE 8800 8800 306.969 4439.88 2.257722e-02 0 Col GE 9000 9000 324.456 4493.54 2.347010e-02 11 cases: 11 passed, 0 skipped, 0 failed 4707.78 real 9019.12 user 38.34 sys o ULE sysctl kern.sched.name ; /usr/bin/time ./xdinvtst_pt -N 7000 9000 200 kern.sched.name: ule NREPS ORDER UPLO N LDA TIME MFLOP RESID ===== ===== ===== ===== ===== ======== ======== ============ 0 Col GE 7000 7000 284.579 2410.49 2.110725e-02 0 Col GE 7200 7200 176.769 4222.87 2.106386e-02 0 Col GE 7400 7400 183.035 4427.67 2.099199e-02 0 Col GE 7600 7600 195.830 4483.10 2.073756e-02 0 Col GE 7800 7800 228.077 4161.20 2.089531e-02 0 Col GE 8000 8000 267.382 3829.61 2.142018e-02 0 Col GE 8200 8200 247.578 4453.95 2.041516e-02 0 Col GE 8400 8400 261.590 4531.42 2.092699e-02 0 Col GE 8600 8600 308.443 4124.18 2.119786e-02 0 Col GE 8800 8800 331.672 4109.20 2.257722e-02 0 Col GE 9000 9000 320.790 4544.91 2.347010e-02 11 cases: 11 passed, 0 skipped, 0 failed 6964.19 real 8720.26 user 34.31 sys o What are my test doing? what is xdinvtst_pt? this program calculates inversion of randomly genrated matrices (double precision). _pt means pthread, and this creates two threads at a time to calculate the inversion of the matrix. We performed calculation from 7000x7000 matrix to 9000x9000 gradually increasing row and column by 200. how to make xdivntst_pt? build math/atlas-devel with smp machine. this port knows # of processors installed. You will build atlas after a very very long time; 1.5 day or so after typing make many times (10-20 times!) since this port is fragile. Then go down the work directory and manually fix some makefiles to point Fortran BLAS/LAPACK (via math/lapack) and can build by yourself. so this is why i included in archive and prepared statically linked binaries. o Perfomance of Opteron and effect of SMP Theoretical peak of calculation in double precision using SSE2 for 1.6GHz opteron is 3.2GFlops, so 6.4GFlops for dual processors. Performance of the largest test (inversion of 9000x9000 matrix in double precision) is about 4.5Gflops. namely 70% of theoretical peak. this is very good. From my experience, best experimental perfomance in single processor is ~80% such achivement might be found at much more primitive calculations. o ULE vs 4BSD please see this row: 4BSD 0 Col GE 9000 9000 324.456 4493.54 2.347010e-02 ule 0 Col GE 9000 9000 320.790 4544.91 2.347010e-02 these line shows 4.5Flops performance by inverting matrix. 324 seconds have passed by 4BSD and 320 seconds have passed by ule. This doesn't mean what I say was wrong; ~320 seconds have passed by both processors. namely ~160 seconds by one processor and ~160 seconds by another processor, then atlas measure as ~320 seconds have passed as total and this is the best case. We definitely need at least 320 seconds to invert the matrix and how actual time has passed is not measured in this context. With ULE, for example ~240 have passed in one processor, and ~80s in another processor. so we *must* wait for 240 seconds, while with 4BSD, we only wait for 160 seconds. we can know from actual difference between ULE and 4BSD by /usr/bin/time 4BSD 4707.78 real 9019.12 user 38.34 sys ULE 6964.19 real 8720.26 user 34.31 sys and 6964.19/4707.78=1.479. ~9000 seconds have passed by 4BSD and 8700s by ULE. and real is ~4700 seconds for 4BSD and ~7000s by ULE. so time consumed by actual works are both same (~9000s and ~8700s). but scheduling is not efficinet for this calculation and so, ULE needs more time. o Scheduling threads / processes? scheduling threads and processes can be different. but other experiments show that if we run same process at a time, ULE is also ~1.5 times slower than 4BSD. o conclusion 4BSD is near the optimal for large calculations and ULE is ~1.5 times slower than 4BSD. Both scheduling algorithm smp aware. I don't think ULE as default is good choice. >How-To-Repeat: described in Full Description section >Fix: none. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Wed Sep 7 03:41: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 6B32516A41F for ; Wed, 7 Sep 2005 03:41:01 +0000 (GMT) (envelope-from chat95@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 285AD43D45 for ; Wed, 7 Sep 2005 03:41:01 +0000 (GMT) (envelope-from chat95@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout03/MantshX 4.0) with ESMTP id j873f0td003345; Tue, 6 Sep 2005 20:41:00 -0700 (PDT) Received: from localhost ([133.11.172.102]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j873euan018894; Tue, 6 Sep 2005 20:40:59 -0700 (PDT) Date: Wed, 07 Sep 2005 12:40:50 +0900 (JST) Message-Id: <20050907.124050.21851139.chat95@mac.com> To: kris@obsecurity.org From: NAKATA Maho In-Reply-To: <20050906000016.GA91835@xor.obsecurity.org> References: <4316A5BC.1000405@meijome.net> <20050906000016.GA91835@xor.obsecurity.org> Organization: private X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: Which SCHED_ for DB server X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2005 03:41:01 -0000 In Message-ID: <20050906000016.GA91835@xor.obsecurity.org> Kris Kennaway wrote: > On Thu, Sep 01, 2005 at 10:53:39AM +0200, Claus Guttesen wrote: > > > I'm building a server that will run PostgreSQL with a database > > > containing several 10s of million records. The only things happening on > > > this box will be the SQL processes and other processes to parse raw data > > > and load into the DB. Users = a few connections via HTTP from an > > > intranet server (not more than 5 concurrently). > > > > > > I was wondering what is the best SCHED_ to set in the kernel. > > > I currently have SCHED_4BSD but was wondering if _ULE would be better > > > for this > > > > For prod. use I would recommend SCHED_4BSD atm. The 4BSD-scheduler > > does seem to be more stable on SMP and up. > > ULE might be OK on SMP with 6.0 and above, but performance seems to be > a bit lower than 4BSD in my tests. Try it yourself and see which is > better. I tried different matter, but my result shows: for 5.4-RELEASE, ule is 1.5 times slower than 4bsd. See also PR: 85820 for details. thanks! -- NAKATA, Maho (maho@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Wed Sep 7 23:50: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 1333016A41F for ; Wed, 7 Sep 2005 23:50:12 +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 530B043D48 for ; Wed, 7 Sep 2005 23:50:11 +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 j87NoBai069431 for ; Wed, 7 Sep 2005 23:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j87NoBKA069430; Wed, 7 Sep 2005 23:50:11 GMT (envelope-from gnats) Resent-Date: Wed, 7 Sep 2005 23:50:11 GMT Resent-Message-Id: <200509072350.j87NoBKA069430@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, Nate Eldredge Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47A5416A41F for ; Wed, 7 Sep 2005 23:48:19 +0000 (GMT) (envelope-from nge@cs.hmc.edu) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by mx1.FreeBSD.org (Postfix) with SMTP id CD92E43D4C for ; Wed, 7 Sep 2005 23:48:18 +0000 (GMT) (envelope-from nge@cs.hmc.edu) Received: (qmail 81909 invoked from network); 7 Sep 2005 23:48:18 -0000 Received: from unknown (HELO mercury.lan) (nattylite@sbcglobal.net@63.206.48.153 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 7 Sep 2005 23:48:18 -0000 Received: from mercury.lan (localhost [127.0.0.1]) by mercury.lan (8.13.3/8.13.3) with ESMTP id j87NmFAb077699 for ; Wed, 7 Sep 2005 16:48:15 -0700 (PDT) (envelope-from nate@mercury.lan) Received: (from nate@localhost) by mercury.lan (8.13.3/8.13.3/Submit) id j87NmFP1077698; Wed, 7 Sep 2005 16:48:15 -0700 (PDT) (envelope-from nate) Message-Id: <200509072348.j87NmFP1077698@mercury.lan> Date: Wed, 7 Sep 2005 16:48:15 -0700 (PDT) From: Nate Eldredge To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: amd64/85852: Typo in amd64 machine/specialreg.h X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nate Eldredge List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2005 23:50:12 -0000 >Number: 85852 >Category: amd64 >Synopsis: Typo in amd64 machine/specialreg.h >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: Wed Sep 07 23:50:10 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Nate Eldredge >Release: FreeBSD 5.4-RELEASE-p6 >Organization: >Environment: System: FreeBSD vulcan.lan 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #0: Sun Sep 4 02:52:11 PDT 2005 nate@vulcan.lan:/usr/obj/usr/src/sys/VULCAN amd64 >Description: There is a mistake in on amd64. The addresses of the MSR_MC3_* and MSR_MC4_* machine check registers are reversed. This would be an issue if somebody implements MCA support someday. I have been playing with this a little myself. >How-To-Repeat: Compare with AMD's documentation. >Fix: --- sys/amd64/include/specialreg.h.orig Wed Sep 7 13:19:24 2005 +++ sys/amd64/include/specialreg.h Wed Sep 7 13:20:03 2005 @@ -198,14 +198,14 @@ #define MSR_MC2_STATUS 0x409 #define MSR_MC2_ADDR 0x40a #define MSR_MC2_MISC 0x40b -#define MSR_MC4_CTL 0x40c -#define MSR_MC4_STATUS 0x40d -#define MSR_MC4_ADDR 0x40e -#define MSR_MC4_MISC 0x40f -#define MSR_MC3_CTL 0x410 -#define MSR_MC3_STATUS 0x411 -#define MSR_MC3_ADDR 0x412 -#define MSR_MC3_MISC 0x413 +#define MSR_MC3_CTL 0x40c +#define MSR_MC3_STATUS 0x40d +#define MSR_MC3_ADDR 0x40e +#define MSR_MC3_MISC 0x40f +#define MSR_MC4_CTL 0x410 +#define MSR_MC4_STATUS 0x411 +#define MSR_MC4_ADDR 0x412 +#define MSR_MC4_MISC 0x413 /* * Constants related to MSR's. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Wed Sep 7 23:58: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 5306C16A41F for ; Wed, 7 Sep 2005 23:58:50 +0000 (GMT) (envelope-from jeff.hamann@forestinformatics.com) Received: from stimpy.forestinformatics.com (cvo-cr1-200-239.peak.org [69.59.200.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C6DF43D49 for ; Wed, 7 Sep 2005 23:58:49 +0000 (GMT) (envelope-from jeff.hamann@forestinformatics.com) Received: from rodan ([192.168.0.14]) by stimpy.forestinformatics.com (8.12.9/8.12.9) with SMTP id j87NwjMc067241 for ; Wed, 7 Sep 2005 16:58:45 -0700 (PDT) (envelope-from jeff.hamann@forestinformatics.com) Message-ID: <002f01c5b408$13f24630$0a00a8c0@rodan> From: "Jeff D. Hamann" To: Date: Wed, 7 Sep 2005 16:58:38 -0700 Organization: Forest Informatics, Inc. 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.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on stimpy.forestinformatics.com Subject: amd64 ad0: TIMEOUT - READ_DMA on boot... X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Jeff D. Hamann" List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2005 23:58:50 -0000 I'm trying to set up a new amd64 FreeBSD 5.4 machine and when I attempt to boot up for the first time (many time by now), I get the following message(s): isa_dmainit(2, 40960) failed blah, blah, blah, then... ad0: 190782MB [387621/16/53] at ata0-master WDMA2 ad0: TIMEOUT - READ_DMA retrying (2 retries left) LBA=390721905 and then the system just hangs and does nothing. I've tried swapping out the IDE cable, same result I've seen some other posts regarding this error and haven't seen a solution. Also, I don't know how to get a dump of the boot process. The hard drive is a brand new western digital 200 GB drive as well. Is this a problem with the amd64 or the 5.4 release or bad hardware or what? Please help, Jeff. --- Jeff D. Hamann Forest Informatics, Inc. PO Box 1421 Corvallis, Oregon USA 97339-1421 541-754-1428 jeff.hamann@forestinformatics.com www.forestinformatics.com From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 00:37:15 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 0AD6916A41F for ; Thu, 8 Sep 2005 00:37:15 +0000 (GMT) (envelope-from fernando@schapachnik.com.ar) Received: from servidor1.cursosvirtuales.com.ar (www.cursosvirtuales.com.ar [200.59.46.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 398DE43D46 for ; Thu, 8 Sep 2005 00:37:13 +0000 (GMT) (envelope-from fernando@schapachnik.com.ar) Received: from servidor1.cursosvirtuales.com.ar (localhost [127.0.0.1]) by servidor1.cursosvirtuales.com.ar (8.12.11/8.12.11) with ESMTP id j880b0bs045007; Wed, 7 Sep 2005 21:37:00 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: from schapachnik.com.ar (uucp@localhost) by servidor1.cursosvirtuales.com.ar (8.12.11/8.12.11/Submit) with UUCP id j880b0Oo045005; Wed, 7 Sep 2005 21:37:00 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: from funes2.schapachnik.com.ar (localhost.schapachnik.com.ar [127.0.0.1]) by funes2.schapachnik.com.ar (8.13.4/8.13.4) with ESMTP id j880asQp000827; Wed, 7 Sep 2005 21:36:54 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) Received: (from fpscha@localhost) by funes2.schapachnik.com.ar (8.13.4/8.13.4/Submit) id j880asSw000826; Wed, 7 Sep 2005 21:36:54 -0300 (ART) (envelope-from fernando@schapachnik.com.ar) X-Authentication-Warning: funes2.schapachnik.com.ar: fpscha set sender to fernando@schapachnik.com.ar using -f Date: Wed, 7 Sep 2005 21:36:54 -0300 From: Fernando Schapachnik To: "Jeff D. Hamann" Message-ID: <20050908003654.GE697@funes2.schapachnik.com.ar> References: <002f01c5b408$13f24630$0a00a8c0@rodan> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <002f01c5b408$13f24630$0a00a8c0@rodan> User-Agent: Mutt/1.4.2.1i X-OS: FreeBSD 4.10 - http://www.freebsd.org Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 ad0: TIMEOUT - READ_DMA on boot... 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, 08 Sep 2005 00:37:15 -0000 En un mensaje anterior, Jeff D. Hamann escribió: > I'm trying to set up a new amd64 FreeBSD 5.4 machine and when I > attempt to boot up for the first time (many time by now), I get > the following message(s): > > isa_dmainit(2, 40960) failed > > blah, blah, blah, then... > > ad0: 190782MB [387621/16/53] at > ata0-master WDMA2 > ad0: TIMEOUT - READ_DMA retrying (2 retries left) LBA=390721905 6.0-BETA solved that for me (although on an old IDE disk). You can also try (at the cost of performance) to disable DMA in the BIOS and/or the OS. Good luck. Fernando P. Schapachnik fernando@schapachnik.com.ar From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 11:37: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 24D4F16A420 for ; Thu, 8 Sep 2005 11:37:53 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E5A643D45 for ; Thu, 8 Sep 2005 11:37:52 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so1051179nzo for ; Thu, 08 Sep 2005 04:37:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=DMhaqqLFLPlGV5vga0ZaUgc+YVCupaFDAeOQMmal4Dfog/mUw88df6tYTKEAnQezurDXSjnp7DqtyH+CBPkqFBk6jfyZ+Pp2JyR8MVw4MYo0MC0nvZzK1/NCEagZbYqwWpXSRmV2VDIJOd06i840encj3mBlN2ucWVIBRpSw3vk= Received: by 10.36.157.18 with SMTP id f18mr6527055nze; Thu, 08 Sep 2005 04:37:51 -0700 (PDT) Received: by 10.36.72.10 with HTTP; Thu, 8 Sep 2005 04:37:51 -0700 (PDT) Message-ID: <28edec3c05090804373a134e01@mail.gmail.com> Date: Thu, 8 Sep 2005 19:37:51 +0800 From: "Mars G. Miro" To: freebsd-amd64@freebsd.org, freebsd-stable@freebsd.org, sos@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: SiI 3114 woes 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, 08 Sep 2005 11:37:53 -0000 Yo list/Soren! Has anybody successfully installed FreeBSD on the dual-Opteron TYAN ThunderK8W S2885 ( http://www.tyan.com/products/html/thunderk8w.html ) using the onboard SiI 3114 SATA controller? This mobo is supposedly supported: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D80857 But I have never been able to successfully install FreeBSD({5.3/5.4/6.0Beta3/4} amd64/i386) on it, using SATA. =20 In my last attempt at installing 6.0Beta4 AMD64 on it, I get: ad4: FAILURE - WRITE_DMA status=3D51 error=3D4 LBA=3D105819039 g_vfs_done():ad4s1e[WRITE(offset=3D23695114240, length=3D2048)]error =3D 5 at the debugging console=20 =20 and=20 =20 panic:bundirty: buffer 0xffffffff9a7faff0 still on queue 1 cpuid =3D 0 KDB: enter: panic [ thread pid 3 tid 100021 ] Stopped at kdb_enter+0x2f: nop db> trace Tracing pid 3 tid 100021 td 0xffffff007ba14be0 kdb_enter() at kdb_enter+0x2f panic() at panic+0x249 bundirty() at bundirty+0x128 brelse() at brelse+0x831 bufdone() at bufdone+0x225 ffs_backgroundwritedone() at ffs_backgroundwritedone+0xa7 bufdone() at bufdone+0x2ad g_vfs_done() at g_gvfs_done+0x63 g_io_schedule_up() at g_io_schedule_up+0xd4 g_up_procbody() at g_up_procbody+0x7a fork_exit() at fork_exit+0xbb fork_trampoline() at fork_tramploine+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffffffb2160d00, rbp =3D 0 ---=20 db> Some months ago, I did successfully install FreeBSD 5.4/amd64 on it, using PATA IDE drives, and no problems whatsoever, so I think this has something to do w/ the SiI 3114 driver. Any help is much appreciated. I do apologize for cross-posting but this concerns -stable and -amd64. Thanks! cheers mars From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 05:30:12 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 59D7A16A41F for ; Thu, 8 Sep 2005 05:30:12 +0000 (GMT) (envelope-from egschweng@hotmail.com) Received: from hotmail.com (bay104-dav13.bay104.hotmail.com [65.54.175.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17A1843D5A for ; Thu, 8 Sep 2005 05:30:12 +0000 (GMT) (envelope-from egschweng@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Sep 2005 22:30:11 -0700 Message-ID: Received: from 65.54.175.200 by BAY104-DAV13.phx.gbl with DAV; Thu, 08 Sep 2005 05:30:11 +0000 X-Originating-IP: [65.54.175.200] X-Originating-Email: [egschweng@hotmail.com] X-Sender: egschweng@hotmail.com From: "Eric Gschweng" To: Date: Wed, 7 Sep 2005 22:30:09 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 08 Sep 2005 05:30:11.0879 (UTC) FILETIME=[6234D370:01C5B436] X-Mailman-Approved-At: Thu, 08 Sep 2005 11:49:06 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ASUS K8V SE + onboard sound recording 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, 08 Sep 2005 05:30:12 -0000 Hi, I'm trying to get the mic working on my K8, and I came across your post = (from over a year and a half ago). I'm hoping your response will include = help aside from telling me to get a new mobo, hahaha. Did you have any = luck? Please let me know. Thanks, Eric From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 11:51: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 33E7916A41F; Thu, 8 Sep 2005 11:51:32 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.178.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9379643D48; Thu, 8 Sep 2005 11:51:31 +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 mailgate1.zdv.Uni-Mainz.DE (Postfix) with ESMTP id DE1153000C2F; Thu, 8 Sep 2005 13:51:29 +0200 (CEST) Message-ID: <43202588.9030903@mail.uni-mainz.de> Date: Thu, 08 Sep 2005 13:50:32 +0200 From: "O. Hartmann" Organization: Institut =?ISO-8859-1?Q?f=FCr_Geophysik?= User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050908) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Malachi_de_=C6lfweald?= References: <431D90E1.1030105@mail.uni-mainz.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Cc: freebsd-questions@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: nForce4-SLI, AHCI and NCQ and FreeBSD 6.0 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, 08 Sep 2005 11:51:32 -0000 Hello. Are you really sure the onboard Sil SATA controller supports SATA II? When I studied the handbook of both motherboards, the A8N-SLI Deluxe and A8N-SLI Premium I found both motherboards are idetically equipted with the *not* SATA II capable SilI3114 SATA controller. By the way, as I know, the second SATA controller is attached via the PCI32 bus, not via PCIe! That means (in my opinion) there is no benefit using this controller. It is more a marketing GAG than a serious add-on. RAID5 performance of ICH7R and SilI is said to be very, very poor (about 10 MB/s read/write performance), so what benefit I do have using this controller with it's senseless 'capabilities' and non-PCIe attachment? This is only a thought based on my personal available informations and maybe wrong ... Oliver Malachi de Ælfweald wrote: > I have noticed the same thing with the onboard Silicon Image controller. > I am using the A8N-SLI Premium. I am using the Silicon Image controller > instead of the nForce4 controller because it specifically said SATAII > and said it supported RAID5 (whereas the nForce did not support RAID5). > However, on boot it recognizes it as SATA150 (which should be SATA300). > > Malachi > > On 9/6/05, *O. Hartmann* > wrote: > > Hello. > I have a little question about the popular nForce4-SLI chipset for the > Socket 939 platform. The onboard SATA controller of the nForce4-SLI > chipset claims to be NCQ (or SATA II) capable, but nVidia implemented > this feature in a not-AHCI-standardised way, but as an own solution. My > question is: Is the FBSD 6.X driver for the nForce4-SLI chipset capable > of using NCQ (as I know, the driver has to enable NCQ and it's not done > automatically by the harddrive-controller interaction). > > Thanks in advance, > Oliver > _______________________________________________ > freebsd-questions@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org > " > > From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 11:53:25 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 5380116A420 for ; Thu, 8 Sep 2005 11:53:25 +0000 (GMT) (envelope-from ohartman@mail.uni-mainz.de) Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.178.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BB6643D5A for ; Thu, 8 Sep 2005 11:53:24 +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 mailgate1.zdv.Uni-Mainz.DE (Postfix) with ESMTP id 4AA543000C2F; Thu, 8 Sep 2005 13:53:23 +0200 (CEST) Message-ID: <43202601.5010505@mail.uni-mainz.de> Date: Thu, 08 Sep 2005 13:52:33 +0200 From: "O. Hartmann" Organization: Institut =?ISO-8859-1?Q?f=FCr_Geophysik?= User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050908) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NAKATA Maho References: <4316A5BC.1000405@meijome.net> <20050906000016.GA91835@xor.obsecurity.org> <20050907.124050.21851139.chat95@mac.com> In-Reply-To: <20050907.124050.21851139.chat95@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-mainz.de Cc: freebsd-amd64@freebsd.org, kris@obsecurity.org Subject: Re: Which SCHED_ for DB server X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 11:53:25 -0000 Hello. That sounds weird. Do you have results for FreeBSD 6.0? Oliver NAKATA Maho wrote: > In Message-ID: <20050906000016.GA91835@xor.obsecurity.org> > Kris Kennaway wrote: > > >>On Thu, Sep 01, 2005 at 10:53:39AM +0200, Claus Guttesen wrote: >> >>>>I'm building a server that will run PostgreSQL with a database >>>>containing several 10s of million records. The only things happening on >>>>this box will be the SQL processes and other processes to parse raw data >>>>and load into the DB. Users = a few connections via HTTP from an >>>>intranet server (not more than 5 concurrently). >>>> >>>>I was wondering what is the best SCHED_ to set in the kernel. >>>>I currently have SCHED_4BSD but was wondering if _ULE would be better >>>>for this >>> >>>For prod. use I would recommend SCHED_4BSD atm. The 4BSD-scheduler >>>does seem to be more stable on SMP and up. >> >>ULE might be OK on SMP with 6.0 and above, but performance seems to be >>a bit lower than 4BSD in my tests. Try it yourself and see which is >>better. > > > I tried different matter, but my result shows: > for 5.4-RELEASE, ule is 1.5 times slower than 4bsd. > See also PR: 85820 for details. > > thanks! > -- NAKATA, Maho (maho@FreeBSD.org) > _______________________________________________ > 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 Sep 8 12:06:31 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 7592D16A41F; Thu, 8 Sep 2005 12:06:31 +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 D9C4043D48; Thu, 8 Sep 2005 12:06:30 +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 j88C0iw2095658; Thu, 8 Sep 2005 14:00:44 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) In-Reply-To: <28edec3c05090804373a134e01@mail.gmail.com> References: <28edec3c05090804373a134e01@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <81C53E0D-FBD4-44CF-B3A4-56ED99BE6090@FreeBSD.ORG> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Thu, 8 Sep 2005 14:06:25 +0200 To: "Mars G. Miro" X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-stable@FreeBSD.ORG, freebsd-amd64@FreeBSD.ORG Subject: Re: SiI 3114 woes 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, 08 Sep 2005 12:06:31 -0000 On 08/09/2005, at 13:37, Mars G. Miro wrote: > Yo list/Soren! > > Has anybody successfully installed FreeBSD on the dual-Opteron TYAN > ThunderK8W S2885 ( http://www.tyan.com/products/html/thunderk8w.html ) > using the onboard SiI 3114 SATA controller? This mobo is supposedly > supported: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D80857 > > But I have never been able to successfully install > FreeBSD({5.3/5.4/6.0Beta3/4} amd64/i386) on it, using SATA. > > In my last attempt at installing 6.0Beta4 AMD64 on it, I get: > > ad4: FAILURE - WRITE_DMA status=3D51 = error=3D4 > LBA=3D105819039 > g_vfs_done():ad4s1e[WRITE(offset=3D23695114240, length=3D2048)]error = =3D 5 The drive apparently aborts the write, however this cant be the first =20= operation to it, so something else might have happend before this. On my (granted UP AMD64) it works like a charm, so does it on x86 so =20 the driver is not completely broken at least :) Get me the output from dmesg so I can see whats under the hood, might =20= help explain things. S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 12:28:41 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 4EAB216A41F; Thu, 8 Sep 2005 12:28:41 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 832C843D45; Thu, 8 Sep 2005 12:28:40 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j88CSdi9074569; Thu, 8 Sep 2005 08:28:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j88CSdjP035791; Thu, 8 Sep 2005 08:28:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0DBAC7302F; Thu, 8 Sep 2005 08:28:38 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050908122838.0DBAC7302F@freebsd-current.sentex.ca> Date: Thu, 8 Sep 2005 08:28:38 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 12:28:41 -0000 TB --- 2005-09-08 10:24:29 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-09-08 10:24:29 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-09-08 10:24:29 - cleaning the object tree TB --- 2005-09-08 10:24:59 - checking out the source tree TB --- 2005-09-08 10:24:59 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-09-08 10:24:59 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-09-08 10:30:39 - building world (CFLAGS=-O2 -pipe) TB --- 2005-09-08 10:30:39 - cd /src TB --- 2005-09-08 10:30:39 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2005-09-08 12:01:17 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-08 12:01:17 - cd /src TB --- 2005-09-08 12:01:17 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Sep 8 12:01:17 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Thu Sep 8 12:16:51 UTC 2005 TB --- 2005-09-08 12:16:51 - generating LINT kernel config TB --- 2005-09-08 12:16:51 - cd /src/sys/amd64/conf TB --- 2005-09-08 12:16:51 - /usr/bin/make -B LINT TB --- 2005-09-08 12:16:51 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-08 12:16:51 - cd /src TB --- 2005-09-08 12:16:51 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 8 12:16:51 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/fdc/fdc_acpi.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/fdc/fdc_isa.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/fdc/fdc_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/hptmv/entry.c /src/sys/dev/hptmv/entry.c: In function `hpt_action': /src/sys/dev/hptmv/entry.c:2170: error: invalid type argument of `->' /src/sys/dev/hptmv/entry.c:2170: error: invalid type argument of `->' /src/sys/dev/hptmv/entry.c:2170: error: invalid type argument of `->' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-09-08 12:28:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-09-08 12:28:38 - ERROR: failed to build lint kernel TB --- 2005-09-08 12:28:38 - tinderbox aborted From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 14:59: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 F3DF716A41F for ; Thu, 8 Sep 2005 14:59:00 +0000 (GMT) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (glewis.dsl.xmission.com [166.70.56.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AC6143D45 for ; Thu, 8 Sep 2005 14:59:00 +0000 (GMT) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.13.3/8.13.3) with ESMTP id j88Ewv15022299; Thu, 8 Sep 2005 08:58:58 -0600 (MDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.13.3/8.13.3/Submit) id j88EwtNh022298; Thu, 8 Sep 2005 08:58:55 -0600 (MDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Thu, 8 Sep 2005 08:58:55 -0600 From: Greg Lewis To: Fernando Schapachnik Message-ID: <20050908145855.GA22080@misty.eyesbeyond.com> References: <431842CA.4030008@mail.uni-mainz.de> <20050902150653.GA78096@misty.eyesbeyond.com> <6.2.3.4.0.20050903213157.047f8560@193.189.169.9> <20050903211134.GA1573@misty.eyesbeyond.com> <20050904233013.GC672@funes2.schapachnik.com.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050904233013.GC672@funes2.schapachnik.com.ar> User-Agent: Mutt/1.4.2.1i Cc: "O. Hartmann" , freebsd-amd64@freebsd.org Subject: Re: Stable and working JAVA for pure 64 Bit environment? 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, 08 Sep 2005 14:59:01 -0000 On Sun, Sep 04, 2005 at 08:30:13PM -0300, Fernando Schapachnik wrote: > En un mensaje anterior, Greg Lewis escribi?: > > > >The java/jdk15 port. > > > > > > Just dont try to build it on 5.x :) It wont work. 6beta can build it just > > > fine. > > Any idea where glibc-common-2.3.2-4.80.8.amd64.rpm and > company can be found? There is no such thing. FreeBSD/amd64 only does i386 Linux emulation. The linux_base* ports do this correctly when you install them directly. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 16:57:38 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 D0C2416A41F for ; Thu, 8 Sep 2005 16:57:38 +0000 (GMT) (envelope-from jeff.hamann@forestinformatics.com) Received: from stimpy.forestinformatics.com (cvo-cr1-200-239.peak.org [69.59.200.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BFC443D46 for ; Thu, 8 Sep 2005 16:57:38 +0000 (GMT) (envelope-from jeff.hamann@forestinformatics.com) Received: from rodan ([192.168.0.14]) by stimpy.forestinformatics.com (8.12.9/8.12.9) with SMTP id j88GvZMc069400 for ; Thu, 8 Sep 2005 09:57:35 -0700 (PDT) (envelope-from jeff.hamann@forestinformatics.com) Message-ID: <001801c5b496$68b40710$0a00a8c0@rodan> From: "Jeff D. Hamann" To: Date: Thu, 8 Sep 2005 09:57:28 -0700 Organization: Forest Informatics, Inc. 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.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on stimpy.forestinformatics.com Subject: can't see onboard NIC X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Jeff D. Hamann" List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 16:57:38 -0000 Hi, I've been trying to get FreeBSD-6BETA up and running (after having some troubles trying to get 5.4 running) on a new AMD64 system. The system is an ASUS vintage-ae1 with an onboard NIC (I'm not what kind other info I can provide since the web link for the mb specs is down on the asus website)... When I run dmesg, I get the following lines (I can't post the whole thing since I can't get files from the bsd box to my windows box -- no mcopy and I don't knwo how to mount the usb stick either): plip0: on ppbus0 and when I type ifonfig, I get: plip0: flags=<108851 mtu 1500 lo0: flags=blah,blah,blah.... and that's it. So my questions are: 1) how do I get the nic up? kernel recompile? how and with what settings? It seems there are a gazillion ethernet interfaces already in the /usr/src/sys/amd64/conf/GENERIC file. Do I need to add the entry for in the /boot/device.hints file? Is there a way to do this without a kernel recompile using some settings in the /boot/defaults/loader.conf file? 2) how do I get the usb mounted (or even better automounted)? 3) I'm guessing that I need to make changes to the kernel in /usr/src/sys/amd64 and not /usr/src/sys/i386, Yes? Also, I've tried to simply insert a usb stick into the front port and when I removed the device, the machine rebooted. Is there any more information I can provide to help solve this? Thanks, Jeff. --- Jeff D. Hamann Forest Informatics, Inc. PO Box 1421 Corvallis, Oregon USA 97339-1421 541-754-1428 jeff.hamann@forestinformatics.com www.forestinformatics.com From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 18:40: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 0FAFE16A41F for ; Thu, 8 Sep 2005 18:40:51 +0000 (GMT) (envelope-from jeff.hamann@forestinformatics.com) Received: from stimpy.forestinformatics.com (cvo-cr1-200-239.peak.org [69.59.200.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FFB943D45 for ; Thu, 8 Sep 2005 18:40:50 +0000 (GMT) (envelope-from jeff.hamann@forestinformatics.com) Received: from rodan ([192.168.0.14]) by stimpy.forestinformatics.com (8.12.9/8.12.9) with SMTP id j88IefMc069608 for ; Thu, 8 Sep 2005 11:40:41 -0700 (PDT) (envelope-from jeff.hamann@forestinformatics.com) Message-ID: <002f01c5b4a4$cfb04880$0a00a8c0@rodan> From: "Jeff D. Hamann" To: Date: Thu, 8 Sep 2005 11:40:29 -0700 Organization: Forest Informatics, Inc. 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.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on stimpy.forestinformatics.com Subject: don't know how to make buildkernel... X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Jeff D. Hamann" List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 18:40:51 -0000 I've just put together a new amd64 machine in an ASUS Vintage-ae1 barebones system. After giving up on FreeBSD 5.4 when it gagged on my hard drive, I decided to try going all the way to 6.0beta4. Almost everything went without incident except for mounting usb sticks and the on-board network card isn't coming up. It seems to get detected, but not initialized. When I run dmesg, I get the following lines (I can't post the whole thing since I can't get files from the bsd box to my windows box -- no mcopy and I don't know how to mount the usb stick either): plip0: on ppbus0 and when I type ifonfig, I get: plip0: flags=<108851 mtu 1500 lo0: flags=blah,blah,blah.... I think my chipsets for the asus vintage-ae1 is/are: northbridge: SIS 760GX southbridge: SIS 965L and so doing a little research, I think the sis device driver might work (maybe?) and so I might need to recompile the kernel to get the onboard nic to light up, right? I've been hunting around to see if I can recompile the kernel to include the SIS ethernet driver and I'm having some trouble with the process of building a new kernel under 6.0-BETA4... >From re-reading my references, compiling a new kernel is accomplished with the following steps: 1) cd /sys/amd64/conf 2) cp KERNEL MYKERNEL 3) make the edits to MYKERNEL (adding the line "device sis" to the file) 4) cd /usr/src 5) make buildkernel KERNCONF=MYKERNEL 6) make installkernel KERNCONF=MYKERNEL 7) reboot okay, so when I attempt to build a new kernel, I get the following: bobby# make buildkernel KERNCONF=MYKERNEL make: don't know how to make buildkernel. Stop bobby# now what? Jeff --- Jeff D. Hamann Forest Informatics, Inc. PO Box 1421 Corvallis, Oregon USA 97339-1421 541-754-1428 jeff.hamann@forestinformatics.com www.forestinformatics.com From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 18:44: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 BD19416A41F for ; Thu, 8 Sep 2005 18:44:21 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C44C43D5D for ; Thu, 8 Sep 2005 18:44:16 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j88IiB0r020561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2005 14:44:11 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j88IiA6P008858; Thu, 8 Sep 2005 14:44:11 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5C3235127A; Thu, 8 Sep 2005 14:44:10 -0400 (EDT) Date: Thu, 8 Sep 2005 14:44:10 -0400 From: Kris Kennaway To: "Jeff D. Hamann" Message-ID: <20050908184409.GA66079@xor.obsecurity.org> References: <002f01c5b4a4$cfb04880$0a00a8c0@rodan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <002f01c5b4a4$cfb04880$0a00a8c0@rodan> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: don't know how to make buildkernel... 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, 08 Sep 2005 18:44:21 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 08, 2005 at 11:40:29AM -0700, Jeff D. Hamann wrote: > >From re-reading my references, compiling a new kernel is accomplished wi= th=20 > the following steps: >=20 > 1) cd /sys/amd64/conf > 2) cp KERNEL MYKERNEL > 3) make the edits to MYKERNEL (adding the line "device sis" to the file) > 4) cd /usr/src > 5) make buildkernel KERNCONF=3DMYKERNEL > 6) make installkernel KERNCONF=3DMYKERNEL > 7) reboot >=20 > okay, so when I attempt to build a new kernel, I get the following: >=20 > bobby# make buildkernel KERNCONF=3DMYKERNEL > make: don't know how to make buildkernel. Stop > bobby# >=20 > now what? Are you sure you have the full source tree installed? Kris --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDIIZ5Wry0BWjoQKURApiBAJ4/kStAGzGIJdKLJ2vjhnnXBFon5gCgtT3Z jtgZ/N+ujsl2g/3jbkS2axw= =1n1Z -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 18:47:54 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 B23EC16A420 for ; Thu, 8 Sep 2005 18:47:54 +0000 (GMT) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC03343D46 for ; Thu, 8 Sep 2005 18:47:53 +0000 (GMT) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr14.xs4all.nl (8.13.3/8.13.3) with ESMTP id j88IleB1039857; Thu, 8 Sep 2005 20:47:40 +0200 (CEST) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 33D586325; Thu, 8 Sep 2005 20:47:40 +0200 (CEST) Date: Thu, 8 Sep 2005 20:47:40 +0200 From: Roland Smith To: "Jeff D. Hamann" Message-ID: <20050908184740.GB69004@slackbox.xs4all.nl> Mail-Followup-To: "Jeff D. Hamann" , freebsd-amd64@freebsd.org References: <001801c5b496$68b40710$0a00a8c0@rodan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8P1HSweYDcXXzwPJ" Content-Disposition: inline In-Reply-To: <001801c5b496$68b40710$0a00a8c0@rodan> 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: can't see onboard NIC 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, 08 Sep 2005 18:47:54 -0000 --8P1HSweYDcXXzwPJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 08, 2005 at 09:57:28AM -0700, Jeff D. Hamann wrote: > Hi, >=20 > I've been trying to get FreeBSD-6BETA up and running (after having some= =20 > troubles trying to get 5.4 running) on a new AMD64 system. The system is = an=20 > ASUS vintage-ae1 with an onboard NIC (I'm not what kind other info I can= =20 > provide since the web link for the mb specs is down on the asus website).= .. > and that's it. So my questions are: >=20 > 1) how do I get the nic up? kernel recompile? how and with what settings?= =20 > It seems there are a gazillion ethernet interfaces already in the=20 > /usr/src/sys/amd64/conf/GENERIC file. Do I need to add the entry for in t= he=20 > /boot/device.hints file? Is there a way to do this without a kernel=20 > recompile using some settings in the /boot/defaults/loader.conf file? If the kernel did not load a module, it could be that it's just not recognized. Does running 'pciconf -lv' give any more into on the type of nic you have? Without information about the type of nic nobody can tell you if it will work. > 2) how do I get the usb mounted (or even better automounted)? You mean an USB storage device? See my FreeBSD page: http://www.xs4all.nl/~rsmith/freebsd/#hotplug In short: - plug in your device - see if a 'da' device pops up, typically da0s1 or da0s4 if you have no other 'da' devices active. - mount the device 'mount -t msdosfs /dev/da0s1 /mnt/usbdrive' The problem is, that if you have more than one usb storage device, the allocation of the device node depends when they are plugged in. The first will be da0, the second da1 etc. To make your life easier, write a label to the usb device with glabel, so next time you plug it in, a device node will appear in /dev/label/, with the (unique) name you have given it. That would make it possible to include the devise in /etc/fstab and the automounter setup. > 3) I'm guessing that I need to make changes to the kernel in=20 > /usr/src/sys/amd64 and not /usr/src/sys/i386, Yes? Yes. What I do is the following; I've got a directory ~/setup/kernel where my kernel configuration resides under revision control (I'm using subversion, but you could also use rcs or cvs or numbered copies, whatever takes your fancy). I started by copying /usr/src/sys/amd64/conf/GENERIC to ~/setup/kernel/MYKERNEL. I've registered this in the revision control system. Then I started editing the MYKERNEL. When I want to try a changed configuration, I first check it in to the revision control system. Then I copy MYKERNEL to /usr/src/sys/amd64/conf/. I've added KERNCONF=3DMYKERNEL to /etc/make.conf. Then I rebuild and install the kernel as per the handbook. Ny using revision control I can always check exactly what I've changed in the kernel configuration between kernel builds. So if I break something, I know how to unbreak it. After installation but before building a new kernel, I recursively copy /boot/kernel to /boot/kernel.generic, so I can always fall back on a known working kernel. > Also, I've tried to simply insert a usb stick into the front port and whe= n=20 > I removed the device, the machine rebooted. That is definitely a bug. Which USB driver are you using? The ehci driver (usb 2.0) had a reputation of being somewhat buggy. Try uhci or ohci instead. =20 > Is there any more information I can provide to help solve this? Set your machine up to save crashdumps (see the developers handbook). 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 --8P1HSweYDcXXzwPJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDIIdMEnfvsMMhpyURAlx7AJ9B/k1jYrLbuInl+Vp2+UPPXiGcKwCfaKyT zNNbQQ6Ut0TJ9BxeQLMGfws= =pILg -----END PGP SIGNATURE----- --8P1HSweYDcXXzwPJ-- From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 18:57: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 94DCC16A420 for ; Thu, 8 Sep 2005 18:57:46 +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 0F28E43D45 for ; Thu, 8 Sep 2005 18:57:46 +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 j88IvjDP008382; Thu, 8 Sep 2005 11:57:45 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j88Ivjel008381; Thu, 8 Sep 2005 11:57:45 -0700 (PDT) (envelope-from obrien) Date: Thu, 8 Sep 2005 11:57:45 -0700 From: "David O'Brien" To: "Mars G. Miro" Message-ID: <20050908185745.GA5587@dragon.NUXI.org> References: <28edec3c05090804373a134e01@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28edec3c05090804373a134e01@mail.gmail.com> X-Operating-System: FreeBSD 7.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: SiI 3114 woes 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, 08 Sep 2005 18:57:46 -0000 On Thu, Sep 08, 2005 at 07:37:51PM +0800, Mars G. Miro wrote: > But I have never been able to successfully install > FreeBSD({5.3/5.4/6.0Beta3/4} amd64/i386) on it, using SATA. How much memory is in your system? I repeatedly panic when I try to use a SiI3114 RAID1 with 8GB RAM. Though my traceback looks quite different from yours. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 19:03: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 0793B16A41F for ; Thu, 8 Sep 2005 19:03:29 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F0B543D46 for ; Thu, 8 Sep 2005 19:03:23 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j88J3MZd039299 for ; Thu, 8 Sep 2005 13:03:22 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <43208AFA.6060101@samsco.org> Date: Thu, 08 Sep 2005 13:03:22 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-amd64@freebsd.org References: <28edec3c05090804373a134e01@mail.gmail.com> <20050908185745.GA5587@dragon.NUXI.org> In-Reply-To: <20050908185745.GA5587@dragon.NUXI.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Subject: Re: SiI 3114 woes 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, 08 Sep 2005 19:03:29 -0000 David O'Brien wrote: > On Thu, Sep 08, 2005 at 07:37:51PM +0800, Mars G. Miro wrote: > >> But I have never been able to successfully install >>FreeBSD({5.3/5.4/6.0Beta3/4} amd64/i386) on it, using SATA. > > > How much memory is in your system? I repeatedly panic when I try to use > a SiI3114 RAID1 with 8GB RAM. Though my traceback looks quite different > from yours. > I think that we've talked before about how that ATA driver, which the SiI chips fall under, simply is written wrong to handle >4GB of RAM. Scott From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 19:14:09 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 6AE9116A41F for ; Thu, 8 Sep 2005 19:14:09 +0000 (GMT) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13EDF43D55 for ; Thu, 8 Sep 2005 19:14:07 +0000 (GMT) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr15.xs4all.nl (8.13.3/8.13.3) with ESMTP id j88JDuNI039343; Thu, 8 Sep 2005 21:13:56 +0200 (CEST) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id C568D6325; Thu, 8 Sep 2005 21:13:55 +0200 (CEST) Date: Thu, 8 Sep 2005 21:13:55 +0200 From: Roland Smith To: "Jeff D. Hamann" Message-ID: <20050908191355.GC69004@slackbox.xs4all.nl> Mail-Followup-To: "Jeff D. Hamann" , freebsd-amd64@freebsd.org References: <002f01c5b4a4$cfb04880$0a00a8c0@rodan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UPT3ojh+0CqEDtpF" Content-Disposition: inline In-Reply-To: <002f01c5b4a4$cfb04880$0a00a8c0@rodan> 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: don't know how to make buildkernel... 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, 08 Sep 2005 19:14:09 -0000 --UPT3ojh+0CqEDtpF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 08, 2005 at 11:40:29AM -0700, Jeff D. Hamann wrote: > I've just put together a new amd64 machine in an ASUS Vintage-ae1 barebon= es=20 > system. After giving up on FreeBSD 5.4 when it gagged on my hard drive, I= =20 > decided to try going all the way to 6.0beta4. Almost everything went=20 > without incident except for mounting usb sticks and the on-board network= =20 > card isn't coming up. It seems to get detected, but not initialized. >=20 > When I run dmesg, I get the following lines (I can't post the whole thing= =20 > since I can't get files from the bsd box to my windows box -- no mcopy an= d=20 > I don't know how to mount the usb stick either): >=20 > plip0: on ppbus0 This is not your network card, but the parallel port internet protocol driv= er. > northbridge: SIS 760GX > southbridge: SIS 965L =46rom the documentation on the Sis website, the 760 chipset has a southbridge 964 for networking (among other things). http://www.sis.com/products/sis760_features.htm > and so doing a little research, I think the sis device driver might work= =20 > (maybe?) and so I might need to recompile the kernel to get the onboard n= ic=20 > to light up, right? The sis device is configured in the GENERIC kernel on amd64. So if it's not recognized, this particular chip might not be supported by the driver. Are there any lines starting with 'sis' in the dmesg output? > I've been hunting around to see if I can recompile the=20 > kernel to include the SIS ethernet driver and I'm having some trouble wit= h=20 > the process of building a new kernel under 6.0-BETA4... >=20 > >From re-reading my references, compiling a new kernel is accomplished wi= th=20 > the following steps: >=20 > 1) cd /sys/amd64/conf > 2) cp KERNEL MYKERNEL > 3) make the edits to MYKERNEL (adding the line "device sis" to the file) device sis is enabled in the GENERIC kernel on amd64: slackbox:~$ grep sis /usr/src/sys/amd64/conf/GENERIC device sis # Silicon Integrated Systems SiS 900/SiS 70= 16 > okay, so when I attempt to build a new kernel, I get the following: >=20 > bobby# make buildkernel KERNCONF=3DMYKERNEL > make: don't know how to make buildkernel. Stop > bobby# >=20 > now what? Are you sure you are in /usr/src? Do you have the kernel source installed? 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 --UPT3ojh+0CqEDtpF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDII1zEnfvsMMhpyURAi7aAJ0VNH0h1RRqmmtzpS98NiUrMHFPrwCeIfY6 TAQQEgkjqfMaUKHNIaw+qlg= =gvxl -----END PGP SIGNATURE----- --UPT3ojh+0CqEDtpF-- From owner-freebsd-amd64@FreeBSD.ORG Thu Sep 8 21:23: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 3922116A425; Thu, 8 Sep 2005 21:23:05 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: from ngwee.ugcs.caltech.edu (ngwee.ugcs.caltech.edu [131.215.176.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2B3B43D46; Thu, 8 Sep 2005 21:23:04 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by ngwee.ugcs.caltech.edu (Postfix, from userid 3640) id 8BB96CC071; Thu, 8 Sep 2005 14:22:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ngwee.ugcs.caltech.edu (Postfix) with ESMTP id 009E2BD0A5; Thu, 8 Sep 2005 14:22:54 -0700 (PDT) Date: Thu, 8 Sep 2005 14:22:54 -0700 (PDT) From: Jon Dama To: "Mars G. Miro" In-Reply-To: <28edec3c05090804373a134e01@mail.gmail.com> Message-ID: References: <28edec3c05090804373a134e01@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org, sos@freebsd.org Subject: Re: SiI 3114 woes 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, 08 Sep 2005 21:23:06 -0000 Yes, but only in a configuration <=3GB. But I thought those problems were ironed out? I've been looking to switch that machine back to FreeBSD/amd64 but haven't had a chance yet. Would love to know if there are issues ahead. -Jon On Thu, 8 Sep 2005, Mars G. Miro wrote: > Yo list/Soren! > > Has anybody successfully installed FreeBSD on the dual-Opteron TYAN > ThunderK8W S2885 ( http://www.tyan.com/products/html/thunderk8w.html ) > using the onboard SiI 3114 SATA controller? This mobo is supposedly > supported: > http://www.freebsd.org/cgi/query-pr.cgi?pr=80857 > > But I have never been able to successfully install > FreeBSD({5.3/5.4/6.0Beta3/4} amd64/i386) on it, using SATA. > > In my last attempt at installing 6.0Beta4 AMD64 on it, I get: > > ad4: FAILURE - WRITE_DMA status=51 error=4 > LBA=105819039 > g_vfs_done():ad4s1e[WRITE(offset=23695114240, length=2048)]error = 5 > > at the debugging console > > and > > panic:bundirty: buffer 0xffffffff9a7faff0 still on queue 1 > cpuid = 0 > KDB: enter: panic > [ thread pid 3 tid 100021 ] > Stopped at kdb_enter+0x2f: nop > db> trace > Tracing pid 3 tid 100021 td 0xffffff007ba14be0 > kdb_enter() at kdb_enter+0x2f > panic() at panic+0x249 > bundirty() at bundirty+0x128 > brelse() at brelse+0x831 > bufdone() at bufdone+0x225 > ffs_backgroundwritedone() at ffs_backgroundwritedone+0xa7 > bufdone() at bufdone+0x2ad > g_vfs_done() at g_gvfs_done+0x63 > g_io_schedule_up() at g_io_schedule_up+0xd4 > g_up_procbody() at g_up_procbody+0x7a > fork_exit() at fork_exit+0xbb > fork_trampoline() at fork_tramploine+0xe > --- trap 0, rip = 0, rsp = 0xffffffffb2160d00, rbp = 0 --- > db> > > Some months ago, I did successfully install FreeBSD 5.4/amd64 on it, > using PATA IDE drives, and no problems whatsoever, so I think this has > something to do w/ the SiI 3114 driver. > > Any help is much appreciated. > > I do apologize for cross-posting but this concerns -stable and -amd64. > > Thanks! > > > cheers > mars > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-amd64@FreeBSD.ORG Fri Sep 9 06:57: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 AC46816A424 for ; Fri, 9 Sep 2005 06:57:37 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A6CB43D55 for ; Fri, 9 Sep 2005 06:57:36 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: by zproxy.gmail.com with SMTP id z31so3048758nzd for ; Thu, 08 Sep 2005 23:57:35 -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:in-reply-to:mime-version:content-type:references; b=Mlfd4ZQQ0GyJ4QIklqo22dJiP//ADZwN/t6KWsAw6HVN24PSQ3bR4/xfIi6DJ/4/nFzwXlfNjD9Tr19JYu0/eisaSE6T54iydJMMFVQK/+xgepsqoumTdOWXZQdRzIrFVCnAM6wIGSYQNeeeh5ohh5T9gPoU/Hp6PVWKhD9HZXw= Received: by 10.36.251.12 with SMTP id y12mr40894nzh; Thu, 08 Sep 2005 23:57:35 -0700 (PDT) Received: by 10.36.72.10 with HTTP; Thu, 8 Sep 2005 23:57:35 -0700 (PDT) Message-ID: <28edec3c050908235713439533@mail.gmail.com> Date: Fri, 9 Sep 2005 14:57:35 +0800 From: "Mars G. Miro" To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= , freebsd-amd64@freebsd.org, freebsd-stable@freebsd.org In-Reply-To: <81C53E0D-FBD4-44CF-B3A4-56ED99BE6090@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_820_30961451.1126249055662" References: <28edec3c05090804373a134e01@mail.gmail.com> <81C53E0D-FBD4-44CF-B3A4-56ED99BE6090@FreeBSD.ORG> Cc: Subject: Re: SiI 3114 woes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: marsgmiro@gmail.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 06:57:37 -0000 ------=_Part_820_30961451.1126249055662 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 9/8/05, S=F8ren Schmidt wrote: >=20 > On 08/09/2005, at 13:37, Mars G. Miro wrote: >=20 > > Yo list/Soren! > > > > Has anybody successfully installed FreeBSD on the dual-Opteron TYAN > > ThunderK8W S2885 ( http://www.tyan.com/products/html/thunderk8w.html ) > > using the onboard SiI 3114 SATA controller? This mobo is supposedly > > supported: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D80857 > > > > But I have never been able to successfully install > > FreeBSD({5.3/5.4/6.0Beta3/4} amd64/i386) on it, using SATA. > > > > In my last attempt at installing 6.0Beta4 AMD64 on it, I get: > > > > ad4: FAILURE - WRITE_DMA status=3D51 error=3D4 > > LBA=3D105819039 > > g_vfs_done():ad4s1e[WRITE(offset=3D23695114240, length=3D2048)]error = =3D 5 >=20 > The drive apparently aborts the write, however this cant be the first =20 > operation to it, so something else might have happend before this. > On my (granted UP AMD64) it works like a charm, so does it on x86 so =20 > the driver is not completely broken at least :) >=20 > Get me the output from dmesg so I can see whats under the hood, might =20 > help explain things. >=20 It's attached. I should also mention that the BIOS is teh latest version (2.05) w/ the SiI 3114 flash version to be 5.049. Thanks! > S=F8ren Schmidt > sos@FreeBSD.org >=20 >=20 >=20 >=20 cheers mars ------=_Part_820_30961451.1126249055662 Content-Type: text/plain; name="dmesgk8w.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesgk8w.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDYuMC1CRVRBNCAjMDogVHVlIFNlcCAgNiAyMDowMDo1OSBV VEMgMjAwNQogICAgcm9vdEByYXQuc2Ftc2NvLmhvbWU6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VO RVJJQwpXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJm b3JtYW5jZS4KUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJuZWwiIGF0IDB4 ZmZmZmZmZmY4MGRlNDAwMC4KUHJlbG9hZGVkIG1mc19yb290ICIvYm9vdC9tZnNyb290IiBhdCAw eGZmZmZmZmZmODBkZTQxYTguCkNhbGlicmF0aW5nIGNsb2NrKHMpIC4uLiBpODI1NCBjbG9jazog MTE5MzE1NSBIegpDTEtfVVNFX0k4MjU0X0NBTElCUkFUSU9OIG5vdCBzcGVjaWZpZWQgLSB1c2lu ZyBkZWZhdWx0IGZyZXF1ZW5jeQpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgy IEh6IHF1YWxpdHkgMApDYWxpYnJhdGluZyBUU0MgY2xvY2sgLi4uIFRTQyBjbG9jazogMTc5MzE4 ODI1MyBIegpDUFU6IEFNRCBPcHRlcm9uKHRtKSBQcm9jZXNzb3IgMjQ0ICgxNzkzLjE5LU1IeiBL OC1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkF1dGhlbnRpY0FNRCIgIElkID0gMHhmNWEgIFN0ZXBw aW5nID0gMTAKICBGZWF0dXJlcz0weDc4YmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUs TUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxNTVgs RlhTUixTU0UsU1NFMj4KICBBTUQgRmVhdHVyZXM9MHhlMDUwMDgwMDxTWVNDQUxMLE5YLE1NWCss TE0sM0ROb3crLDNETm93PgpMMSAyTUIgZGF0YSBUTEI6IDggZW50cmllcywgZnVsbHkgYXNzb2Np YXRpdmUKTDEgMk1CIGluc3RydWN0aW9uIFRMQjogOCBlbnRyaWVzLCBmdWxseSBhc3NvY2lhdGl2 ZQpMMSA0S0IgZGF0YSBUTEI6IDMyIGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIDRLQiBp bnN0cnVjdGlvbiBUTEI6IDMyIGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIGRhdGEgY2Fj aGU6IDY0IGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDItd2F5IGFzc29jaWF0 aXZlCkwxIGluc3RydWN0aW9uIGNhY2hlOiA2NCBrYnl0ZXMsIDY0IGJ5dGVzL2xpbmUsIDEgbGlu ZXMvdGFnLCAyLXdheSBhc3NvY2lhdGl2ZQpMMiAyTUIgdW5pZmllZCBUTEI6IDAgZW50cmllcywg ZGlzYWJsZWQvbm90IHByZXNlbnQKTDIgNEtCIGRhdGEgVExCOiA1MTIgZW50cmllcywgNC13YXkg YXNzb2NpYXRpdmUKTDIgNEtCIGluc3RydWN0aW9uIFRMQjogNTEyIGVudHJpZXMsIDQtd2F5IGFz c29jaWF0aXZlCkwyIHVuaWZpZWQgY2FjaGU6IDEwMjQga2J5dGVzLCA2NCBieXRlcy9saW5lLCAx IGxpbmVzL3RhZywgMTYtd2F5IGFzc29jaWF0aXZlCnJlYWwgbWVtb3J5ICA9IDIxNDc0MTgxMTIg KDIwNDcgTUIpClBoeXNpY2FsIG1lbW9yeSBjaHVuayhzKToKMHgwMDAwMDAwMDAwMDAxMDAwIC0g MHgwMDAwMDAwMDAwMDliZmZmLCA2MzQ4ODAgYnl0ZXMgKDE1NSBwYWdlcykKMHgwMDAwMDAwMDAw ZWUxMDAwIC0gMHgwMDAwMDAwMDdjM2FmZmZmLCAyMDY4NjM5NzQ0IGJ5dGVzICg1MDUwMzkgcGFn ZXMpCmF2YWlsIG1lbW9yeSA9IDIwNTg1MDYyNDAgKDE5NjMgTUIpCndsYW46IDw4MDIuMTEgTGlu ayBMYXllcj4KbnVsbDogPG51bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4KcmFuZG9tOiA8ZW50cm9w eSBzb3VyY2UsIFNvZnR3YXJlLCBZYXJyb3c+Cm5mc2xvY2s6IHBzZXVkby1kZXZpY2UKbWVtOiA8 bWVtb3J5PgppbzogPEkvTz4KYWNwaTA6IDxBIE0gSSBPRU1YU0RUPiBvbiBtb3RoZXJib2FyZAph Y3BpMDogW01QU0FGRV0KcGNpX29wZW4oMSk6CW1vZGUgMSBhZGRyIHBvcnQgKDB4MGNmOCkgaXMg MHg4MDAwY2I4MApwY2lfb3BlbigxYSk6CW1vZGUxcmVzPTB4ODAwMDAwMDAgKDB4ODAwMDAwMDAp CnBjaV9jZmdjaGVjazoJZGV2aWNlIDAgMSAyIDMgNCA1IDYgW2NsYXNzPTA2MDQwMF0gW2hkcj0w MV0gaXMgdGhlcmUgKGlkPTc0NjAxMDIyKQpBY3BpT3NEZXJpdmVQY2lJZDogYnVzIDAgZGV2IDcg ZnVuYyAwCkFjcGlPc0Rlcml2ZVBjaUlkOiBidXMgMCBkZXYgNyBmdW5jIDEKQWNwaU9zRGVyaXZl UGNpSWQ6IGJ1cyAwIGRldiA3IGZ1bmMgMwphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKcGNp X2xpbmswOiA8QUNQSSBQQ0kgTGluayBMTktBPiBpcnEgOSBvbiBhY3BpMApwY2lfbGluazA6IExp bmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAw ICAgIDkgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazA6IExp bmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK ICAgIDAgICAgOSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5r MDogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAg IDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTogPEFD UEkgUENJIExpbmsgTE5LQj4gaXJxIDExIG9uIGFjcGkwCnBjaV9saW5rMTogTGlua3MgYWZ0ZXIg aW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMSAgIE4g ICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMTogTGlua3MgYWZ0ZXIg aW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgIDEx ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxOiBMaW5rcyBh ZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAg ICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsyOiA8QUNQSSBQQ0kgTGlu ayBMTktDPiBpcnEgMCBvbiBhY3BpMApwY2lfbGluazI6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJv YmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAzIDQg NSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazI6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFs aWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAg IDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMjogTGlua3MgYWZ0ZXIgZGlzYWJs ZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1 IDYgNyA5IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMzogPEFDUEkgUENJIExpbmsgTE5LRD4gaXJx IDEwIG9uIGFjcGkwCnBjaV9saW5rMzogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMCAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEw IDExIDEyIDE0IDE1CnBjaV9saW5rMzogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgIDEwICAgTiAgICAgMCAgMyA0IDUgNiA3 IDkgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmszOiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAg SVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAg MTEgMTIgMTQgMTUKQUNQSSB0aW1lcjogMS8xIDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAx LzEgMS8xIC0+IDEwClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6 IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4g cG9ydCAweDUwMDgtMHg1MDBiIG9uIGFjcGkwCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKYWNw aV90aHJvdHRsZTA6IDxBQ1BJIENQVSBUaHJvdHRsaW5nPiBvbiBjcHUwCmFjcGlfdGhyb3R0bGUw OiBQX0NOVCBmcm9tIFBfQkxLIDB4NTAxMApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBw b3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBj aTA6IHBoeXNpY2FsIGJ1cz0wCmZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4NzQ2MCwgcmV2 aWQ9MHgwNwoJYnVzPTAsIHNsb3Q9NiwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0w eDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMTE3LCBzdGF0cmVnPTB4MDIzMCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwNiAoMTUwMCBucyks IG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDc0NjgsIHJl dmlkPTB4MDUKCWJ1cz0wLCBzbG90PTcsIGZ1bmM9MAoJY2xhc3M9MDYtMDEtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwZiwgc3RhdHJlZz0weDAyMjAsIGNhY2hlbG5zej0w IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHg3NDY5LCByZXZpZD0w eDAzCglidXM9MCwgc2xvdD03LCBmdW5jPTEKCWNsYXNzPTAxLTAxLThhLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjAwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQoJbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykKCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGZmYTAsIHNp emUgIDQsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHg3NDZhLCByZXZpZD0w eDAyCglidXM9MCwgc2xvdD03LCBmdW5jPTIKCWNsYXNzPTBjLTA1LTAwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTAKCWNtZHJlZz0weDAwMDEsIHN0YXRyZWc9MHgwMjAwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCglpbnRwaW49ZCwgaXJxPTEwCgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMy LCBiYXNlIDAwMDBjNDAwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjcuSU5URCAoc3JjIFxcX1NCXy5MTktEOjApCnBjaWIwOiBzbG90IDcgSU5URCByb3V0ZWQg dG8gaXJxIDEwIHZpYSBcXF9TQl8uTE5LRApmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDc0 NmIsIHJldmlkPTB4MDUKCWJ1cz0wLCBzbG90PTcsIGZ1bmM9MwoJY2xhc3M9MDYtODAtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAyODAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHg3NDZk LCByZXZpZD0weDAzCglidXM9MCwgc2xvdD03LCBmdW5jPTUKCWNsYXNzPTA0LTAxLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjAwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTExCgltYXBbMTBdOiB0eXBlIDQs IHJhbmdlIDMyLCBiYXNlIDAwMDBjODAwLCBzaXplICA4LCBlbmFibGVkCgltYXBbMTRdOiB0eXBl IDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBjYzAwLCBzaXplICA2LCBlbmFibGVkCnBjaWIwOiBtYXRj aGVkIGVudHJ5IGZvciAwLjcuSU5UQiAoc3JjIFxcX1NCXy5MTktCOjApCnBjaWIwOiBzbG90IDcg SU5UQiByb3V0ZWQgdG8gaXJxIDExIHZpYSBcXF9TQl8uTE5LQgpmb3VuZC0+CXZlbmRvcj0weDEw MjIsIGRldj0weDc0NTAsIHJldmlkPTB4MTIKCWJ1cz0wLCBzbG90PTEwLCBmdW5jPTAKCWNsYXNz PTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTEKCWNtZHJlZz0weDAxMTcsIHN0YXRyZWc9 MHgwMjMwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1p bmdudD0weDA1ICgxMjUwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4 MTAyMiwgZGV2PTB4NzQ1MSwgcmV2aWQ9MHgwMQoJYnVzPTAsIHNsb3Q9MTAsIGZ1bmM9MQoJY2xh c3M9MDgtMDAtMTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNiwgc3RhdHJl Zz0weDAyMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCW1hcFsxMF06IHR5cGUgMSwgcmFu Z2UgNjQsIGJhc2UgZmM5ZmYwMDAsIHNpemUgMTIsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHgx MDIyLCBkZXY9MHg3NDUwLCByZXZpZD0weDEyCglidXM9MCwgc2xvdD0xMSwgZnVuYz0wCgljbGFz cz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgwMTE2LCBzdGF0cmVn PTB4MDIzMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBt aW5nbnQ9MHgwNSAoMTI1MCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0w eDEwMjIsIGRldj0weDc0NTEsIHJldmlkPTB4MDEKCWJ1cz0wLCBzbG90PTExLCBmdW5jPTEKCWNs YXNzPTA4LTAwLTEwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRy ZWc9MHgwMjAwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCgltYXBbMTBdOiB0eXBlIDEsIHJh bmdlIDY0LCBiYXNlIGZjOWZlMDAwLCBzaXplIDEyLCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4 MTAyMiwgZGV2PTB4MTEwMCwgcmV2aWQ9MHgwMAoJYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MAoJY2xh c3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJl Zz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIy LCBkZXY9MHgxMTAxLCByZXZpZD0weDAwCglidXM9MCwgc2xvdD0yNCwgZnVuYz0xCgljbGFzcz0w Ni0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4 MDAwMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRl dj0weDExMDIsIHJldmlkPTB4MDAKCWJ1cz0wLCBzbG90PTI0LCBmdW5jPTIKCWNsYXNzPTA2LTAw LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDAw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4 MTEwMywgcmV2aWQ9MHgwMAoJYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MwoJY2xhc3M9MDYtMDAtMDAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNh Y2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMTAw LCByZXZpZD0weDAwCglidXM9MCwgc2xvdD0yNSwgZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVs bnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDExMDEsIHJl dmlkPTB4MDAKCWJ1cz0wLCBzbG90PTI1LCBmdW5jPTEKCWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDAwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTEwMiwgcmV2aWQ9 MHgwMAoJYnVzPTAsIHNsb3Q9MjUsIGZ1bmM9MgoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgw MCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChk d29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMTAzLCByZXZpZD0weDAw CglidXM9MCwgc2xvdD0yNSwgZnVuYz0zCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAwMCwgY2FjaGVsbnN6PTAgKGR3b3Jk cykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQpwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA2LjAgb24gcGNp MApwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAxCnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAg IDEKcGNpYjE6ICAgSS9PIGRlY29kZSAgICAgICAgMHg5MDAwLTB4YWZmZgpwY2liMTogICBtZW1v cnkgZGVjb2RlICAgICAweGZjNTAwMDAwLTB4ZmM2ZmZmZmYKcGNpYjE6ICAgcHJlZmV0Y2hlZCBk ZWNvZGUgMHhmZmYwMDAwMC0weGZmZmZmCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnBj aTE6IHBoeXNpY2FsIGJ1cz0xCmZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4NzQ2NCwgcmV2 aWQ9MHgwYgoJYnVzPTEsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wYy0wMy0xMCwgaGRydHlwZT0w eDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMTE3LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDUwICgyMDAwMCBucykKCWludHBpbj1kLCBpcnE9MTAKCW1hcFsxMF06IHR5cGUgMSwg cmFuZ2UgMzIsIGJhc2UgZmM2ZmQwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjE6IChudWxsKSBy ZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmM2ZmQwMDAtMHhmYzZmZGZmZjogZ29vZApwY2liMTog bWF0Y2hlZCBlbnRyeSBmb3IgMS4wLklOVEQgKHNyYyBcXF9TQl8uTE5LRDowKQpwY2liMTogc2xv dCAwIElOVEQgcm91dGVkIHRvIGlycSAxMCB2aWEgXFxfU0JfLkxOS0QKZm91bmQtPgl2ZW5kb3I9 MHgxMDIyLCBkZXY9MHg3NDY0LCByZXZpZD0weDBiCglidXM9MSwgc2xvdD0wLCBmdW5jPTEKCWNs YXNzPTBjLTAzLTEwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMTcsIHN0YXRy ZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4NTAgKDIwMDAwIG5zKQoJaW50cGluPWQsIGly cT0xMAoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmYzZmZTAwMCwgc2l6ZSAxMiwg ZW5hYmxlZApwY2liMTogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmYzZmZTAwMC0w eGZjNmZlZmZmOiBnb29kCnBjaWIxOiBtYXRjaGVkIGVudHJ5IGZvciAxLjAuSU5URCAoc3JjIFxc X1NCXy5MTktEOjApCnBjaWIxOiBzbG90IDAgSU5URCByb3V0ZWQgdG8gaXJxIDEwIHZpYSBcXF9T Ql8uTE5LRApmb3VuZC0+CXZlbmRvcj0weDEwOTUsIGRldj0weDMxMTQsIHJldmlkPTB4MDIKCWJ1 cz0xLCBzbG90PTExLCBmdW5jPTAKCWNsYXNzPTAxLTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTAKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykK CWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQy IEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBhYzAw LCBzaXplICAzLCBlbmFibGVkCnBjaWIxOiAobnVsbCkgcmVxdWVzdGVkIEkvTyByYW5nZSAweGFj MDAtMHhhYzA3OiBpbiByYW5nZQoJbWFwWzE0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAw YTgwMCwgc2l6ZSAgMiwgZW5hYmxlZApwY2liMTogKG51bGwpIHJlcXVlc3RlZCBJL08gcmFuZ2Ug MHhhODAwLTB4YTgwMzogaW4gcmFuZ2UKCW1hcFsxOF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2Ug MDAwMGE0MDAsIHNpemUgIDMsIGVuYWJsZWQKcGNpYjE6IChudWxsKSByZXF1ZXN0ZWQgSS9PIHJh bmdlIDB4YTQwMC0weGE0MDc6IGluIHJhbmdlCgltYXBbMWNdOiB0eXBlIDQsIHJhbmdlIDMyLCBi YXNlIDAwMDBhMDAwLCBzaXplICAyLCBlbmFibGVkCnBjaWIxOiAobnVsbCkgcmVxdWVzdGVkIEkv TyByYW5nZSAweGEwMDAtMHhhMDAzOiBpbiByYW5nZQoJbWFwWzIwXTogdHlwZSA0LCByYW5nZSAz MiwgYmFzZSAwMDAwOWMwMCwgc2l6ZSAgNCwgZW5hYmxlZApwY2liMTogKG51bGwpIHJlcXVlc3Rl ZCBJL08gcmFuZ2UgMHg5YzAwLTB4OWMwZjogaW4gcmFuZ2UKCW1hcFsyNF06IHR5cGUgMSwgcmFu Z2UgMzIsIGJhc2UgZmM2ZmZjMDAsIHNpemUgMTAsIGVuYWJsZWQKcGNpYjE6IChudWxsKSByZXF1 ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmM2ZmZjMDAtMHhmYzZmZmZmZjogZ29vZApwY2liMTogbWF0 Y2hlZCBlbnRyeSBmb3IgMS4xMS5JTlRBIChzcmMgXFxfU0JfLkxOS0I6MCkKcGNpYjE6IHNsb3Qg MTEgSU5UQSByb3V0ZWQgdG8gaXJxIDExIHZpYSBcXF9TQl8uTE5LQgpmb3VuZC0+CXZlbmRvcj0w eDEwNGMsIGRldj0weDgwMjMsIHJldmlkPTB4MDAKCWJ1cz0xLCBzbG90PTEyLCBmdW5jPTAKCWNs YXNzPTBjLTAwLTEwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMTYsIHN0YXRy ZWc9MHgwMjEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMp LCBtaW5nbnQ9MHgwMiAoNTAwIG5zKSwgbWF4bGF0PTB4MDQgKDEwMDAgbnMpCglpbnRwaW49YSwg aXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1h cFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmM2ZmYwMDAsIHNpemUgMTEsIGVuYWJsZWQK cGNpYjE6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmM2ZmYwMDAtMHhmYzZmZjdm ZjogZ29vZAoJbWFwWzE0XTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmYzZmODAwMCwgc2l6ZSAx NCwgZW5hYmxlZApwY2liMTogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmYzZmODAw MC0weGZjNmZiZmZmOiBnb29kCnBjaWIxOiBtYXRjaGVkIGVudHJ5IGZvciAxLjEyLklOVEEgKHNy YyBcXF9TQl8uTE5LRDowKQpwY2liMTogc2xvdCAxMiBJTlRBIHJvdXRlZCB0byBpcnEgMTAgdmlh IFxcX1NCXy5MTktECm9oY2kwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG1lbSAw eGZjNmZkMDAwLTB4ZmM2ZmRmZmYgaXJxIDEwIGF0IGRldmljZSAwLjAgb24gcGNpMQpvaGNpMDog UmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhmYzZmZDAwMApv aGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMDogT0hDSSB2ZXJzaW9uIDEuMCwgbGVnYWN5IHN1cHBv cnQKdXNiMDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMAp1c2IwOiBV U0IgcmV2aXNpb24gMS4wCnVodWIwOiBBTUQgT0hDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYg MS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkCm9oY2kxOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGZjNmZl MDAwLTB4ZmM2ZmVmZmYgaXJxIDEwIGF0IGRldmljZSAwLjEgb24gcGNpMQpvaGNpMTogUmVzZXJ2 ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhmYzZmZTAwMApvaGNpMTog W0dJQU5ULUxPQ0tFRF0KdXNiMTogT0hDSSB2ZXJzaW9uIDEuMCwgbGVnYWN5IHN1cHBvcnQKdXNi MTogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMQp1c2IxOiBVU0IgcmV2 aXNpb24gMS4wCnVodWIxOiBBTUQgT0hDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8x LjAwLCBhZGRyIDEKdWh1YjE6IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVk CmF0YXBjaTA6IDxTaUkgMzExNCBTQVRBMTUwIGNvbnRyb2xsZXI+IHBvcnQgMHhhYzAwLTB4YWMw NywweGE4MDAtMHhhODAzLDB4YTQwMC0weGE0MDcsMHhhMDAwLTB4YTAwMywweDljMDAtMHg5YzBm IG1lbSAweGZjNmZmYzAwLTB4ZmM2ZmZmZmYgaXJxIDExIGF0IGRldmljZSAxMS4wIG9uIHBjaTEK YXRhcGNpMDogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4OWMw MAphdGFwY2kwOiBbTVBTQUZFXQphdGFwY2kwOiBSZXNlcnZlZCAweDQwMCBieXRlcyBmb3Igcmlk IDB4MjQgdHlwZSAzIGF0IDB4ZmM2ZmZjMDAKYXRhMjogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBj aTAKYXRhMjogU0FUQSBjb25uZWN0IHJlYWR5IHRpbWU9MG1zCmF0YTI6IHNhdGFfY29ubmVjdCBk ZXZpY2VzPTB4MTxBVEFfTUFTVEVSPgphdGEyOiBbTVBTQUZFXQphdGEzOiA8QVRBIGNoYW5uZWwg MT4gb24gYXRhcGNpMAphdGEzOiBTQVRBIGNvbm5lY3Qgc3RhdHVzPTAwMDAwMDAwCmF0YTM6IFtN UFNBRkVdCmF0YTQ6IDxBVEEgY2hhbm5lbCAyPiBvbiBhdGFwY2kwCmF0YTQ6IFNBVEEgY29ubmVj dCBzdGF0dXM9MDAwMDAwMDAKYXRhNDogW01QU0FGRV0KYXRhNTogPEFUQSBjaGFubmVsIDM+IG9u IGF0YXBjaTAKYXRhNTogU0FUQSBjb25uZWN0IHN0YXR1cz0wMDAwMDAwMAphdGE1OiBbTVBTQUZF XQpmd29oY2kwOiA8VGV4YXMgSW5zdHJ1bWVudHMgVFNCNDNBQjIyL0E+IG1lbSAweGZjNmZmMDAw LTB4ZmM2ZmY3ZmYsMHhmYzZmODAwMC0weGZjNmZiZmZmIGlycSAxMCBhdCBkZXZpY2UgMTIuMCBv biBwY2kxCmZ3b2hjaTA6IFJlc2VydmVkIDB4ODAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMg YXQgMHhmYzZmZjAwMApmd29oY2kwOiBbTVBTQUZFXQpmd29oY2kwOiBPSENJIHZlcnNpb24gMS4x MCAoUk9NPTEpCmZ3b2hjaTA6IE5vLiBvZiBJc29jaHJvbm91cyBjaGFubmVscyBpcyA0Lgpmd29o Y2kwOiBFVUk2NCAwMDplMDo4MTowMDowMDozMDo0NDozZApmd29oY2kwOiBQaHkgMTM5NGEgYXZh aWxhYmxlIFM0MDAsIDIgcG9ydHMuCmZ3b2hjaTA6IExpbmsgUzQwMCwgbWF4X3JlYyAyMDQ4IGJ5 dGVzLgpmaXJld2lyZTA6IDxJRUVFMTM5NChGaXJlV2lyZSkgYnVzPiBvbiBmd29oY2kwCmZ3ZTA6 IDxFdGhlcm5ldCBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAKaWZfZndlMDogRmFrZSBFdGhl cm5ldCBhZGRyZXNzOiAwMjplMDo4MTozMDo0NDozZApmd2UwOiBicGYgYXR0YWNoZWQKZndlMDog RXRoZXJuZXQgYWRkcmVzczogMDI6ZTA6ODE6MzA6NDQ6M2QKZndlMDogaWZfc3RhcnQgcnVubmlu ZyBkZWZlcnJlZCBmb3IgR2lhbnQKc2JwMDogPFNCUC0yL1NDU0kgb3ZlciBGaXJlV2lyZT4gb24g ZmlyZXdpcmUwCmZ3b2hjaTA6IEluaXRpYXRlIGJ1cyByZXNldApmd29oY2kwOiBub2RlX2lkPTB4 YzgwMGZmYzAsIGdlbj0xLCBDWUNMRU1BU1RFUiBtb2RlCmZpcmV3aXJlMDogMSBub2RlcywgbWF4 aG9wIDw9IDAsIGNhYmxlIElSTSA9IDAgKG1lKQpmaXJld2lyZTA6IGJ1cyBtYW5hZ2VyIDAgKG1l KQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAKaXNhMDogPElT QSBidXM+IG9uIGlzYWIwCmF0YXBjaTE6IDxBTUQgODExMSBVRE1BMTMzIGNvbnRyb2xsZXI+IHBv cnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhmZmEwLTB4ZmZhZiBhdCBk ZXZpY2UgNy4xIG9uIHBjaTAKYXRhcGNpMTogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4 MjAgdHlwZSA0IGF0IDB4ZmZhMAphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQphdGFw Y2kxOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMAphdGFw Y2kxOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweDNmNgphdGEw OiByZXNldCB0cDEgbWFzaz0wMiBvc3RhdDA9ZmYgb3N0YXQxPTUwCmF0YTA6IHN0YXQxPTB4MDAg ZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIKYXRhMDogcmVzZXQgdHAyIHN0YXQwPTAwIHN0YXQx PTAwIGRldmljZXM9MHg4PEFUQVBJX1NMQVZFPgphdGEwOiBbTVBTQUZFXQphdGExOiA8QVRBIGNo YW5uZWwgMT4gb24gYXRhcGNpMQphdGFwY2kxOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAw eDE4IHR5cGUgNCBhdCAweDE3MAphdGFwY2kxOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAw eDFjIHR5cGUgNCBhdCAweDM3NgphdGExOiByZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9NjAgb3N0 YXQxPTcwCmF0YTE6IHN0YXQwPTB4MjAgZXJyPTB4MjAgbHNiPTB4MjAgbXNiPTB4MjAKYXRhMTog c3RhdDE9MHgzMCBlcnI9MHgzMCBsc2I9MHgzMCBtc2I9MHgzMAphdGExOiByZXNldCB0cDIgc3Rh dDA9MjAgc3RhdDE9MzAgZGV2aWNlcz0weDAKYXRhMTogW01QU0FGRV0KcGNpMDogPHNlcmlhbCBi dXMsIFNNQnVzPiBhdCBkZXZpY2UgNy4yIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxicmlk Z2U+IGF0IGRldmljZSA3LjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPG11bHRpbWVkaWEs IGF1ZGlvPiBhdCBkZXZpY2UgNy41IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaWIyOiA8QUNQSSBQ Q0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDEwLjAgb24gcGNpMApwY2liMjogICBzZWNvbmRhcnkg YnVzICAgICAyCnBjaWIyOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDIKcGNpYjI6ICAgSS9PIGRlY29k ZSAgICAgICAgMHhiMDAwLTB4YmZmZgpwY2liMjogICBtZW1vcnkgZGVjb2RlICAgICAweGZjNzAw MDAwLTB4ZmM4ZmZmZmYKcGNpYjI6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhkYzIwMDAwMC0weGRj MmZmZmZmCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnBjaTI6IHBoeXNpY2FsIGJ1cz0y CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MTAyNiwgcmV2aWQ9MHgwNAoJYnVzPTIsIHNs b3Q9OCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRy ZWc9MHgwMTE3LCBzdGF0cmVnPTB4MDIzMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1l cj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4ZmYgKDYzNzUwIG5zKSwgbWF4bGF0PTB4MDAgKDAg bnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJl bnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdAoJbWFwWzEwXTogdHlwZSAxLCBy YW5nZSA2NCwgYmFzZSBmYzhlMDAwMCwgc2l6ZSAxNywgZW5hYmxlZApwY2liMjogKG51bGwpIHJl cXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmYzhlMDAwMC0weGZjOGZmZmZmOiBnb29kCgltYXBbMThd OiB0eXBlIDEsIHJhbmdlIDY0LCBiYXNlIGZjODgwMDAwLCBzaXplIDE4LCBlbmFibGVkCnBjaWIy OiAobnVsbCkgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGZjODgwMDAwLTB4ZmM4YmZmZmY6IGdv b2QKCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGJjMDAsIHNpemUgIDYsIGVu YWJsZWQKcGNpYjI6IChudWxsKSByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4YmMwMC0weGJjM2Y6IGlu IHJhbmdlCnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZvciAyLjguSU5UQSAoc3JjIFxcX1NCXy5MTktE OjApCnBjaWIyOiBzbG90IDggSU5UQSByb3V0ZWQgdG8gaXJxIDEwIHZpYSBcXF9TQl8uTE5LRApm b3VuZC0+CXZlbmRvcj0weDE0ZTQsIGRldj0weDE2YTcsIHJldmlkPTB4MDIKCWJ1cz0yLCBzbG90 PTksIGZ1bmM9MAoJY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVn PTB4MDExNiwgc3RhdHJlZz0weDAyYjAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9 MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDQwICgxNjAwMCBucyksIG1heGxhdD0weDAwICgwIG5z KQoJaW50cGluPWEsIGlycT05Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDAKCU1TSSBzdXBwb3J0cyA4IG1lc3NhZ2VzLCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgMSwgcmFu Z2UgNjQsIGJhc2UgZmM4ZDAwMDAsIHNpemUgMTYsIGVuYWJsZWQKcGNpYjI6IChudWxsKSByZXF1 ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmM4ZDAwMDAtMHhmYzhkZmZmZjogZ29vZApwY2liMjogbWF0 Y2hlZCBlbnRyeSBmb3IgMi45LklOVEEgKHNyYyBcXF9TQl8uTE5LQTowKQpwY2liMjogc2xvdCA5 IElOVEEgcm91dGVkIHRvIGlycSA5IHZpYSBcXF9TQl8uTE5LQQplbTA6IDxJbnRlbChSKSBQUk8v MTAwMCBOZXR3b3JrIENvbm5lY3Rpb24sIFZlcnNpb24gLSAyLjEuNz4gcG9ydCAweGJjMDAtMHhi YzNmIG1lbSAweGZjOGUwMDAwLTB4ZmM4ZmZmZmYsMHhmYzg4MDAwMC0weGZjOGJmZmZmIGlycSAx MCBhdCBkZXZpY2UgOC4wIG9uIHBjaTIKZW0wOiBSZXNlcnZlZCAweDIwMDAwIGJ5dGVzIGZvciBy aWQgMHgxMCB0eXBlIDMgYXQgMHhmYzhlMDAwMAplbTA6IFJlc2VydmVkIDB4NDAgYnl0ZXMgZm9y IHJpZCAweDIwIHR5cGUgNCBhdCAweGJjMDAKZW0wOiBbTVBTQUZFXQplbTA6IGJwZiBhdHRhY2hl ZAplbTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjA0OjIzOmI2Ojc1OjJlCmVtMDogIFNwZWVkOk4v QSAgRHVwbGV4Ok4vQQpiZ2UwOiA8QnJvYWRjb20gQkNNNTcwMyBHaWdhYml0IEV0aGVybmV0LCBB U0lDIHJldi4gMHgxMDAyPiBtZW0gMHhmYzhkMDAwMC0weGZjOGRmZmZmIGlycSA5IGF0IGRldmlj ZSA5LjAgb24gcGNpMgpiZ2UwOiBSZXNlcnZlZCAweDEwMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0 eXBlIDMgYXQgMHhmYzhkMDAwMAptaWlidXMwOiA8TUlJIGJ1cz4gb24gYmdlMApicmdwaHkwOiA8 QkNNNTcwMyAxMC8xMDAvMTAwMGJhc2VUWCBQSFk+IG9uIG1paWJ1czAKYnJncGh5MDogIDEwYmFz ZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVFgsIDEw MDBiYXNlVFgtRkRYLCBhdXRvCmJnZTA6IGJwZiBhdHRhY2hlZApiZ2UwOiBFdGhlcm5ldCBhZGRy ZXNzOiAwMDplMDo4MToyYzpiNjpiOApiZ2UwOiBbTVBTQUZFXQpwY2kwOiA8YmFzZSBwZXJpcGhl cmFsLCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDEwLjEgKG5vIGRyaXZlciBhdHRh Y2hlZCkKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTEuMCBvbiBwY2kw CnBjaWIzOiAgIHNlY29uZGFyeSBidXMgICAgIDMKcGNpYjM6ICAgc3Vib3JkaW5hdGUgYnVzICAg MwpwY2liMzogICBJL08gZGVjb2RlICAgICAgICAweDAtMHgwCnBjaWIzOiAgIG1lbW9yeSBkZWNv ZGUgICAgIDB4ZmZmMDAwMDAtMHhmZmZmZgpwY2liMzogICBwcmVmZXRjaGVkIGRlY29kZSAweGZm ZjAwMDAwLTB4ZmZmZmYKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKcGNpMzogcGh5c2lj YWwgYnVzPTMKcGNpMDogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0 IGRldmljZSAxMS4xIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaWI0OiA8QUNQSSBIb3N0LVBDSSBi cmlkZ2U+IG9uIGFjcGkwCnBjaWI0OiBjb3VsZCBub3QgZ2V0IFBDSSBpbnRlcnJ1cHQgcm91dGlu ZyB0YWJsZSBmb3IgXFxfU0JfLlBDSUIgLSBBRV9OT1RfRk9VTkQKcGNpNDogPEFDUEkgUENJIGJ1 cz4gb24gcGNpYjQKcGNpNDogcGh5c2ljYWwgYnVzPTQKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBk ZXY9MHg3NDU0LCByZXZpZD0weDE0CglidXM9NCwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTA2LTAw LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMjEw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCgltYXBbMTBdOiB0eXBlIDMsIHJhbmdlIDMyLCBi YXNlIGYwMDAwMDAwLCBzaXplIDI3LCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2 PTB4NzQ1NSwgcmV2aWQ9MHgxNAoJYnVzPTQsIHNsb3Q9MSwgZnVuYz0wCgljbGFzcz0wNi0wNC0w MCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDIyMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgw OCAoMjAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQphZ3AwOiA8QU1EIDgxNTEgQUdQIGdyYXBo aWNzIHR1bm5lbD4gbWVtIDB4ZjAwMDAwMDAtMHhmN2ZmZmZmZiBhdCBkZXZpY2UgMC4wIG9uIHBj aTQKQU1ENjQ6IDIgTWlzYy4gQ29udHJvbCB1bml0KHMpIGZvdW5kLgphZ3AwOiBSZXNlcnZlZCAw eDgwMDAwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGYwMDAwMDAwCmFncDA6IGFs bG9jYXRpbmcgR0FUVCBmb3IgYXBlcnR1cmUgb2Ygc2l6ZSAxMjhNCnBjaWI1OiA8QUNQSSBQQ0kt UENJIGJyaWRnZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2k0CnBjaWI1OiAgIHNlY29uZGFyeSBidXMg ICAgIDUKcGNpYjU6ICAgc3Vib3JkaW5hdGUgYnVzICAgNQpwY2liNTogICBJL08gZGVjb2RlICAg ICAgICAweGYwMDAtMHhmZmYKcGNpYjU6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmY2EwMDAwMC0w eGZlYWZmZmZmCnBjaWI1OiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZGM0MDAwMDAtMHhlYzNmZmZm ZgpwY2k1OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNQpwY2k1OiBwaHlzaWNhbCBidXM9NQpmb3Vu ZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAxMTAsIHJldmlkPTB4YjIKCWJ1cz01LCBzbG90PTAs IGZ1bmM9MAoJY2xhc3M9MDMtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4 MDAwNywgc3RhdHJlZz0weDAyYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDQw ICgxOTIwIG5zKSwgbWluZ250PTB4MDUgKDEyNTAgbnMpLCBtYXhsYXQ9MHgwMSAoMjUwIG5zKQoJ aW50cGluPWEsIGlycT0yNTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBE MAoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmZDAwMDAwMCwgc2l6ZSAyNCwgZW5h YmxlZApwY2liNTogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmZDAwMDAwMC0weGZk ZmZmZmZmOiBnb29kCgltYXBbMTRdOiB0eXBlIDMsIHJhbmdlIDMyLCBiYXNlIGUwMDAwMDAwLCBz aXplIDI3LCBlbmFibGVkCnBjaWI1OiAobnVsbCkgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGUw MDAwMDAwLTB4ZTdmZmZmZmY6IGdvb2QKcGNpNTogPGRpc3BsYXksIFZHQT4gYXQgZGV2aWNlIDAu MCAobm8gZHJpdmVyIGF0dGFjaGVkKQphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFj cGkwCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0 IGlycSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBmbGFncyAweDEgaXJxIDEgb24g YXRrYmRjMAphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBieXRlIDAw NjUKYXRrYmQ6IGtleWJvYXJkIElEIDB4NDFhYiAoMikKa2JkMCBhdCBhdGtiZDAKa2JkMDogYXRr YmQwLCBBVCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MSwgZmxhZ3M6MHgzZDAwMDAKYXRrYmQwOiBb R0lBTlQtTE9DS0VEXQpwc20wOiB1bmFibGUgdG8gYWxsb2NhdGUgSVJRCnBzbWNwbnAwOiA8UFMv MiBtb3VzZSBwb3J0PiBpcnEgMTIgb24gYWNwaTAKcHNtMDogY3VycmVudCBjb21tYW5kIGJ5dGU6 MDA2NQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzAKcHNtMDogW0dJQU5ULUxP Q0tFRF0KcHNtMDogbW9kZWwgSW50ZWxsaU1vdXNlIEV4cGxvcmVyLCBkZXZpY2UgSUQgNC0wMCwg NSBidXR0b25zCnBzbTA6IGNvbmZpZzowMDAwMDAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tldCBz aXplOjQKcHNtMDogc3luY21hc2s6MDgsIHN5bmNiaXRzOjAwCnNpbzA6IGlycSBtYXBzOiAweDQw MSAweDQxMSAweDQwMSAweDQwMQpzaW8wOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBv cnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMApzaW8wOiB0eXBlIDE2NTUw QQpzaW8xOiBpcnEgbWFwczogMHg0MDEgMHg0MDkgMHg0MDEgMHg0MDEKc2lvMTogPDE2NTUwQS1j b21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGFjcGkwCnNpbzE6 IHR5cGUgMTY1NTBBCmZkYzA6IDxmbG9wcHkgZHJpdmUgY29udHJvbGxlciAoRkRFKT4gcG9ydCAw eDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBhY3BpMApmZGMwOiBpY190eXBlIDkwIHBh cnRfaWQgODAKZmRjMDogW01QU0FGRV0KZmRjMDogW0ZBU1RdCmRldmljZV9hdHRhY2g6IGZkYzAg YXR0YWNoIHJldHVybmVkIDEyCmZkYzA6IDxmbG9wcHkgZHJpdmUgY29udHJvbGxlciAoRkRFKT4g cG9ydCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBhY3BpMApmZGMwOiBpY190eXBl IDkwIHBhcnRfaWQgODAKZmRjMDogW01QU0FGRV0KZmRjMDogW0ZBU1RdCmRldmljZV9hdHRhY2g6 IGZkYzAgYXR0YWNoIHJldHVybmVkIDEyCmF0a2JkYzogYXRrYmRjMCBhbHJlYWR5IGV4aXN0czsg c2tpcHBpbmcgaXQKZmRjOiBmZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApzaW86IHNp bzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnNpbzogc2lvMSBhbHJlYWR5IGV4aXN0czsg c2tpcHBpbmcgaXQKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDIwMwpwbnBfaWRl bnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjQzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRf UG9ydCBhdCAyODMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDJjMwpwbnBfaWRl bnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzAzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRf UG9ydCBhdCAzNDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDM4MwpwbnBfaWRl bnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgM2MzClBOUCBJZGVudGlmeSBjb21wbGV0ZQpleF9p c2FfaWRlbnRpZnkoKQphaGNfaXNhX3Byb2JlIDk6IGlvcG9ydCAweDljMDAgYWxsb2MgZmFpbGVk CmFoY19pc2FfcHJvYmUgMTA6IGlvcG9ydCAweGFjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2FfcHJv YmUgMTE6IGlvcG9ydCAweGJjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2FfcHJvYmUgMTI6IGlvcG9y dCAweGNjMDAgYWxsb2MgZmFpbGVkCnNjOiBzYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0 CnZnYTogdmdhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2NoaWxkcmVu OiBkaXNhYmxpbmcgUG5QIGRldmljZXMKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIG5vbi1Q blAgZGV2aWNlcwpvcm0wOiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4Y2QwMDAtMHhkMTdm ZiBvbiBpc2EwCnBwYzA6IGNhbm5vdCByZXNlcnZlIEkvTyBwb3J0IHJhbmdlCnBwYzA6IDxQYXJh bGxlbCBwb3J0PiBmYWlsZWQgdG8gcHJvYmUgYXQgaXJxIDcgb24gaXNhMApzYzA6IDxTeXN0ZW0g Y29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25z b2xlcywgZmxhZ3M9MHgzMDA+CnNjMDogZmIwLCBrYmQwLCB0ZXJtaW5hbCBlbXVsYXRvcjogc2Mg KHN5c2NvbnMgdGVybWluYWwpCnNpbzI6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpzaW8zOiBub3Qg cHJvYmVkIChkaXNhYmxlZCkKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0w eDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMAppc2FfcHJvYmVfY2hpbGRyZW46IHBy b2JpbmcgUG5QIGRldmljZXMKRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuClJlZHVjaW5n IGtlcm4ubWF4dm5vZGVzIDEzMjQ2MiAtPiAxMDAwMDAKcHJvY2ZzIHJlZ2lzdGVyZWQKbGlucHJv Y2ZzIHJlZ2lzdGVyZWQKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDE3OTMxODgyNTMgSHog cXVhbGl0eSA4MDAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpMaW51eCBFTEYg ZXhlYyBoYW5kbGVyIGluc3RhbGxlZApsbzA6IGJwZiBhdHRhY2hlZAplbTA6IExpbmsgaXMgdXAg MTAwIE1icHMgRnVsbCBEdXBsZXgKbWQwOiBQcmVsb2FkZWQgaW1hZ2UgPC9ib290L21mc3Jvb3Q+ IDQxOTQzMDQgYnl0ZXMgYXQgMHhmZmZmZmZmZjgwOWUyNjkwCmF0YTAtc2xhdmU6IHBpbz1QSU80 IHdkbWE9V0RNQTIgdWRtYT1VRE1BMzMgY2FibGU9NDAgd2lyZQphY2QwOiBzZXR0aW5nIFBJTzQg b24gQU1EIDgxMTEgY2hpcAphY2QwOiBzZXR0aW5nIFVETUEzMyBvbiBBTUQgODExMSBjaGlwCmFj ZDA6IDxDRC0yMjRFLzEuOUE+IENEUk9NIGRyaXZlIGF0IGF0YTAgYXMgc2xhdmUKYWNkMDogcmVh ZCA0MTM0S0IvcyAoNDEzNEtCL3MpLCAxMjhLQiBidWZmZXIsIFVETUEzMwphY2QwOiBSZWFkczog Q0RSLCBDRFJXLCBDRERBIHN0cmVhbSwgcGFja2V0CmFjZDA6IFdyaXRlczoKYWNkMDogQXVkaW86 IHBsYXksIDI1NiB2b2x1bWUgbGV2ZWxzCmFjZDA6IE1lY2hhbmlzbTogZWplY3RhYmxlIHRyYXks IHVubG9ja2VkCmFjZDA6IE1lZGl1bTogQ0QtUk9NIDEyMG1tIGRhdGEgZGlzYwphdGEwLW1hc3Rl cjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUExMzMgY2FibGU9NDAgd2lyZQphZDQ6IDEx NDQ5OE1CIDxTQU1TVU5HIFNQMTIxM0MgU1YxMDAtMzQ+IGF0IGF0YTItbWFzdGVyIFNBVEExNTAK YWQ0OiAyMzQ0OTMwNTYgc2VjdG9ycyBbMjMyNjMyQy8xNkgvNjNTXSAxNiBzZWN0b3JzL2ludGVy cnVwdCAxIGRlcHRoIHF1ZXVlCmFkNDogU2lsaWNvbiBJbWFnZSBjaGVjazEgZmFpbGVkCmFkNDog QWRhcHRlYyBjaGVjazEgZmFpbGVkCmFkNDogTFNJICh2MykgY2hlY2sxIGZhaWxlZAphZDQ6IExT SSAodjIpIGNoZWNrMSBmYWlsZWQKYWQ0OiBGcmVlQlNEIGNoZWNrMSBmYWlsZWQKR0VPTTogbmV3 IGRpc2sgYWQ0Cihwcm9iZTA6c2JwMDowOjA6MCk6IGVycm9yIDIyCihwcm9iZTA6c2JwMDowOjA6 MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTE6c2JwMDowOjE6MCk6IGVycm9yIDIyCihwcm9i ZTE6c2JwMDowOjE6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTI6c2JwMDowOjI6MCk6IGVy cm9yIDIyCihwcm9iZTI6c2JwMDowOjI6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTM6c2Jw MDowOjM6MCk6IGVycm9yIDIyCihwcm9iZTM6c2JwMDowOjM6MCk6IFVucmV0cnlhYmxlIEVycm9y Cihwcm9iZTU6c2JwMDowOjU6MCk6IGVycm9yIDIyCihwcm9iZTU6c2JwMDowOjU6MCk6IFVucmV0 cnlhYmxlIEVycm9yCihwcm9iZTY6c2JwMDowOjY6MCk6IGVycm9yIDIyCihwcm9iZTY6c2JwMDow OjY6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTQ6c2JwMDowOjQ6MCk6IGVycm9yIDIyCihw cm9iZTQ6c2JwMDowOjQ6MCk6IFVucmV0cnlhYmxlIEVycm9yCkFUQSBQc2V1ZG9SQUlEIGxvYWRl ZApUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L21kMApzdGFydF9pbml0OiB0cnlp bmcgL3NiaW4vaW5pdApzdGFydF9pbml0OiB0cnlpbmcgL3NiaW4vb2luaXQKc3RhcnRfaW5pdDog dHJ5aW5nIC9zYmluL2luaXQuYmFrCnN0YXJ0X2luaXQ6IHRyeWluZyAvcmVzY3VlL2luaXQKc3Rh cnRfaW5pdDogdHJ5aW5nIC9zdGFuZC9zeXNpbnN0YWxsCmVtMDogTGluayBpcyB1cCAxMDAgTWJw cyBGdWxsIER1cGxleAo= ------=_Part_820_30961451.1126249055662-- From owner-freebsd-amd64@FreeBSD.ORG Fri Sep 9 07:01: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 6CD9616A41F for ; Fri, 9 Sep 2005 07:01:53 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7A3643D68 for ; Fri, 9 Sep 2005 07:01:52 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: by zproxy.gmail.com with SMTP id z31so3049118nzd for ; Fri, 09 Sep 2005 00:01:52 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GhK3fqwTXGgKHfuGrPHhPya2M2lkCsbMILvHv3AT0zVEQWBDITlT5ON/4MNK9sZ14/CWzQyJWjwh8lRT8Bqf/JenEMsB3Z0Vs2mbxRwcvm1tCqIAAY5dPd/F594s4Jecg0OdjG6Q1t3p4C0/xW2XpTptQkMc6cGy1SbZ5q0joOs= Received: by 10.36.10.2 with SMTP id 2mr58942nzj; Fri, 09 Sep 2005 00:01:52 -0700 (PDT) Received: by 10.36.72.10 with HTTP; Fri, 9 Sep 2005 00:01:52 -0700 (PDT) Message-ID: <28edec3c05090900013497ef2d@mail.gmail.com> Date: Fri, 9 Sep 2005 15:01:52 +0800 From: "Mars G. Miro" To: David O'Brien , freebsd-amd64@freebsd.org In-Reply-To: <20050908185745.GA5587@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <28edec3c05090804373a134e01@mail.gmail.com> <20050908185745.GA5587@dragon.NUXI.org> Cc: Subject: Re: SiI 3114 woes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: marsgmiro@gmail.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 07:01:53 -0000 On 9/9/05, David O'Brien wrote: > On Thu, Sep 08, 2005 at 07:37:51PM +0800, Mars G. Miro wrote: > > But I have never been able to successfully install > > FreeBSD({5.3/5.4/6.0Beta3/4} amd64/i386) on it, using SATA. >=20 > How much memory is in your system? I repeatedly panic when I try to use > a SiI3114 RAID1 with 8GB RAM. Though my traceback looks quite different > from yours. > =20 2G. 1G for each CPU. Full dmesg in my previous email. The controller is configured as a plain drive, not RAID. Thanks! > --=20 > -- David (obrien@FreeBSD.org) >=20 cheers mars From owner-freebsd-amd64@FreeBSD.ORG Fri Sep 9 07:39: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 301AD16A420 for ; Fri, 9 Sep 2005 07:39:22 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64CBB43D48 for ; Fri, 9 Sep 2005 07:39:21 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: by zproxy.gmail.com with SMTP id z31so3052125nzd for ; Fri, 09 Sep 2005 00:39:20 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JkO+NpOJ5QcysDwPBshNjMpZtU3Td95fbKCUYrn1MBynQp3ufztGQoJmZ/654NOrF1d5NpjMeeBur3MDEzn2kapr0T754KM3gj/TKIsB0IT2hGJqNw9fHDmQpf+pHPeCd0hpJV184vTcjLoPmcX6eJWk8JUAzPAi/tviU6xTJek= Received: by 10.36.5.3 with SMTP id 3mr61931nze; Fri, 09 Sep 2005 00:39:20 -0700 (PDT) Received: by 10.36.72.10 with HTTP; Fri, 9 Sep 2005 00:39:20 -0700 (PDT) Message-ID: <28edec3c050909003950052d19@mail.gmail.com> Date: Fri, 9 Sep 2005 15:39:20 +0800 From: "Mars G. Miro" To: Jon Dama , freebsd-amd64@freebsd.org, freebsd-stable@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <28edec3c05090804373a134e01@mail.gmail.com> Cc: Subject: Re: SiI 3114 woes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: marsgmiro@gmail.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 07:39:22 -0000 On 9/9/05, Jon Dama wrote: > Yes, but only in a configuration <=3D3GB. But I thought those problems w= ere > ironed out? I've been looking to switch that machine back to > FreeBSD/amd64 but haven't had a chance yet. Would love to know if there > are issues ahead. >=20 This machine only has 2G of RAM. See my previous post on the full dmesg. Thanks. > -Jon >=20 > On Thu, 8 Sep 2005, Mars G. Miro wrote: >=20 > > Yo list/Soren! > > > > Has anybody successfully installed FreeBSD on the dual-Opteron TYAN > > ThunderK8W S2885 ( http://www.tyan.com/products/html/thunderk8w.html ) > > using the onboard SiI 3114 SATA controller? This mobo is supposedly > > supported: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D80857 > > > > But I have never been able to successfully install > > FreeBSD({5.3/5.4/6.0Beta3/4} amd64/i386) on it, using SATA. > > > > In my last attempt at installing 6.0Beta4 AMD64 on it, I get: > > > > ad4: FAILURE - WRITE_DMA status=3D51 error=3D4 > > LBA=3D105819039 > > g_vfs_done():ad4s1e[WRITE(offset=3D23695114240, length=3D2048)]error = =3D 5 > > > > at the debugging console > > > > and > > > > panic:bundirty: buffer 0xffffffff9a7faff0 still on queue 1 > > cpuid =3D 0 > > KDB: enter: panic > > [ thread pid 3 tid 100021 ] > > Stopped at kdb_enter+0x2f: nop > > db> trace > > Tracing pid 3 tid 100021 td 0xffffff007ba14be0 > > kdb_enter() at kdb_enter+0x2f > > panic() at panic+0x249 > > bundirty() at bundirty+0x128 > > brelse() at brelse+0x831 > > bufdone() at bufdone+0x225 > > ffs_backgroundwritedone() at ffs_backgroundwritedone+0xa7 > > bufdone() at bufdone+0x2ad > > g_vfs_done() at g_gvfs_done+0x63 > > g_io_schedule_up() at g_io_schedule_up+0xd4 > > g_up_procbody() at g_up_procbody+0x7a > > fork_exit() at fork_exit+0xbb > > fork_trampoline() at fork_tramploine+0xe > > --- trap 0, rip =3D 0, rsp =3D 0xffffffffb2160d00, rbp =3D 0 --- > > db> > > > > Some months ago, I did successfully install FreeBSD 5.4/amd64 on it, > > using PATA IDE drives, and no problems whatsoever, so I think this has > > something to do w/ the SiI 3114 driver. > > > > Any help is much appreciated. > > > > I do apologize for cross-posting but this concerns -stable and -amd64. > > > > Thanks! > > > > > > cheers > > mars > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" > > >=20 cheers mars From owner-freebsd-amd64@FreeBSD.ORG Fri Sep 9 07:57:48 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 990F716A421 for ; Fri, 9 Sep 2005 07:57:48 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3D6343D49 for ; Fri, 9 Sep 2005 07:57:47 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: by zproxy.gmail.com with SMTP id z31so3053694nzd for ; Fri, 09 Sep 2005 00:57:47 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NcxZH7YsqsSI7238JSeK+mNgpeGPsZXr90KsFOWSy1AB4Nq/z/7EIcY6/bB9qgMVv5Nr0EtttSntOX6rqe5Q86VGoVCV118H9AI1u5nGS7DbNl2Yc4T6NcsSuQKyeHxdzkonb0sR/7i9Pmth0M7s1ExV3F94Kema1zK3JTNw7rI= Received: by 10.36.79.11 with SMTP id c11mr83432nzb; Fri, 09 Sep 2005 00:57:47 -0700 (PDT) Received: by 10.36.72.10 with HTTP; Fri, 9 Sep 2005 00:57:47 -0700 (PDT) Message-ID: <28edec3c05090900574bc131c4@mail.gmail.com> Date: Fri, 9 Sep 2005 15:57:47 +0800 From: "Mars G. Miro" To: Spartak Radchenko , freebsd-amd64@freebsd.org, sos@freebsd.org In-Reply-To: <20050908145632.GA89468@oberon.aif.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <28edec3c05090804373a134e01@mail.gmail.com> <20050908145632.GA89468@oberon.aif.ru> Cc: Subject: Re: SiI 3114 woes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: marsgmiro@gmail.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 07:57:48 -0000 On 9/8/05, Spartak Radchenko wrote: > On Thu, Sep 08, 2005 at 07:37:51PM +0800, Mars G. Miro wrote: > > Yo list/Soren! > >=20 > > Has anybody successfully installed FreeBSD on the dual-Opteron TYAN > > ThunderK8W S2885 ( http://www.tyan.com/products/html/thunderk8w.html ) > > using the onboard SiI 3114 SATA controller? This mobo is supposedly > > supported: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D80857 >=20 > I have Thunder K8SR (S2881). The same SiI 3114. It works OK (almost). > I couldn't get ATA RAID working properly, gmirror is used instead. >=20 Soren mentioned it works for him but his was a UP AMD64 machine. Any chance you are only using 1 CPU in your S2881 ? Thanks. > --=20 > Spartak Radchenko SVR1-RIPE >=20 cheers mars From owner-freebsd-amd64@FreeBSD.ORG Fri Sep 9 09:17:55 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 7686416A41F for ; Fri, 9 Sep 2005 09:17:55 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F34443D46 for ; Fri, 9 Sep 2005 09:17:54 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: by zproxy.gmail.com with SMTP id z31so3060918nzd for ; Fri, 09 Sep 2005 02:17:54 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E/9/xHUFXx8I2AH58Psxh2Qf59Sd2b462rkfqlZdEX7zmpCM9SiF4QzjOayF2Z435znUQfphZURYZE3LfoIVgbpjvmXauKHRKvJQrRCeSb/QJUxOuzR5BW4+0KHPBxbitKr48HPhTvTwQkSpnLoB8kWAcMnggsDocxj3qYsEbzM= Received: by 10.36.215.14 with SMTP id n14mr139524nzg; Fri, 09 Sep 2005 02:17:54 -0700 (PDT) Received: by 10.36.72.10 with HTTP; Fri, 9 Sep 2005 02:17:53 -0700 (PDT) Message-ID: <28edec3c050909021723539ab9@mail.gmail.com> Date: Fri, 9 Sep 2005 17:17:53 +0800 From: "Mars G. Miro" To: Spartak Radchenko , sos@freebsd.org, freebsd-amd64@freebsd.org In-Reply-To: <20050909080807.GA3865@oberon.aif.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <28edec3c05090804373a134e01@mail.gmail.com> <20050908145632.GA89468@oberon.aif.ru> <28edec3c05090900574bc131c4@mail.gmail.com> <20050909080807.GA3865@oberon.aif.ru> Cc: Subject: Re: SiI 3114 woes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: marsgmiro@gmail.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 09:17:55 -0000 On 9/9/05, Spartak Radchenko wrote: > On Fri, Sep 09, 2005 at 03:57:47PM +0800, Mars G. Miro wrote: > > On 9/8/05, Spartak Radchenko wrote: > > > On Thu, Sep 08, 2005 at 07:37:51PM +0800, Mars G. Miro wrote: > > > > Yo list/Soren! > > > >=20 > > > > Has anybody successfully installed FreeBSD on the dual-Opteron TYA= N > > > > ThunderK8W S2885 ( http://www.tyan.com/products/html/thunderk8w.htm= l > ) > > > > using the onboard SiI 3114 SATA controller? This mobo is supposedl= y > > > > supported: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D80857 > > >=20 > > > I have Thunder K8SR (S2881). The same SiI 3114. It works OK (almost). > > > I couldn't get ATA RAID working properly, gmirror is used instead. > > >=20 > >=20 > > Soren mentioned it works for him but his was a UP AMD64 machine. Any > > chance you are only using 1 CPU in your S2881 ? >=20 > No. Here is my dmesg: >=20 OK. I see that it works for you then. Now I'm at a total loss as to why it doesn't work at all for the S2885 ;-( Thanks, anyway ! > 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-p6 #0: Sat Jul 30 18:34:14 MSD 2005 > spartak@eric.hiero.ru:/usr/obj/usr/src/sys/eric > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Opteron(tm) Processor 244 (1791.92-MHz K8-class CPU) > Origin =3D "AuthenticAMD" Id =3D 0xf5a Stepping =3D 10 > =20 > Features=3D0x78bfbff > AMD Features=3D0xe0500800 > real memory =3D 2147418112 (2047 MB) > avail memory =3D 2063994880 (1968 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-27 on motherboard > ioapic2 irqs 28-31 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 0x1008-0x100b on acpi0 > cpu0: on acpi0 > acpi_throttle0: on cpu0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 6.0 on pci0 > pci3: on pcib1 > ohci0: mem 0xfeafc000-0xfeafcfff irq 19 a= t > device 0.0 on pci3 > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 3 ports with 3 removable, self powered > ohci1: mem 0xfeafd000-0xfeafdfff irq 19 a= t > device 0.1 on pci3 > usb1: OHCI version 1.0, legacy support > usb1: SMM does not respond, resetting > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 3 ports with 3 removable, self powered > atapci0: port > 0xa880-0xa88f,0xac00-0xac03,0xb800-0xb807,0xb880-0xb883,0xbc00-0xbc07 mem > 0xfeafec00-0xfeafefff irq 17 at device > 5.0 on pci3 > ata2: channel #0 on atapci0 > ata3: channel #1 on atapci0 > ata4: channel #2 on atapci0 > ata5: channel #3 on atapci0 > pci3: at device 6.0 (no driver attached) > isab0: at device 7.0 on pci0 > isa0: on isab0 > atapci1: port > 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 > ata0: channel #0 on atapci1 > ata1: channel #1 on atapci1 > pci0: at device 7.2 (no driver attached) > pci0: at device 7.3 (no driver attached) > pcib2: at device 10.0 on pci0 > pci2: on pcib2 > bge0: mem > 0xfc8b0000-0xfc8bffff,0xfc8c0000-0xfc8cffff irq 24 at device 9.0 on pci2 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge0: Ethernet address: 00:e0:81:2f:6c:a4 > bge1: mem > 0xfc8e0000-0xfc8effff,0xfc8f0000-0xfc8fffff irq 25 at device 9.1 on pci2 > miibus1: on bge1 > brgphy1: on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge1: Ethernet address: 00:e0:81:2f:6c:a5 > pci0: at device 10.1 (no driver > attached) > pcib3: at device 11.0 on pci0 > pci1: on pcib3 > pci0: at device 11.1 (no driver > attached) > acpi_button0: on acpi0 > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > sio0: type 16550A > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 = on > acpi0 > orm0: at iomem > 0xcf800-0xd07ff,0xce000-0xcf7ff,0xcc800-0xcdfff,0xc8000-0xcc7ff,0xc0000-0= xc7fff > on isa0 > ppc0: cannot reserve I/O port range > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > acd0: CDROM at ata0-master PIO4 > ad4: 152627MB [310101/16/63] at ata2-maste= r > SATA150 > GEOM_MIRROR: Device gm0 created (id=3D846343504). > GEOM_MIRROR: Device gm0: provider ad4 detected. > ad6: 152627MB [310101/16/63] at ata3-maste= r > SATA150 > GEOM_MIRROR: Device gm0: provider ad6 detected. > GEOM_MIRROR: Device gm0: provider ad6 activated. > GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. > GEOM_MIRROR: Device gm0: rebuilding provider ad4. > SMP: AP CPU #1 Launched! > Mounting root from ufs:/dev/mirror/gm0s1a > Mounting root from ufs:/dev/mirror/gm0s1a > WARNING: / was not properly dismounted > WARNING: /backup was not properly dismounted > WARNING: /tmp was not properly dismounted > WARNING: /usr was not properly dismounted > WARNING: /var was not properly dismounted > WARNING: /jail was not properly dismounted > WARNING: /jail/database was not properly dismounted > /jail/database: mount pending error: blocks 12 files 2 > WARNING: /jail/cache was not properly dismounted > /jail/cache: mount pending error: blocks 576 files 0 >=20 > Messages about rebuilding mirror and "not properly dismounted" are > here because of incorrect shutdown (power loss). >=20 > --=20 > Spartak Radchenko SVR1-RIPE >=20 cheers mars From owner-freebsd-amd64@FreeBSD.ORG Fri Sep 9 11:16: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 0FF5016A41F; Fri, 9 Sep 2005 11:16:30 +0000 (GMT) (envelope-from michael.hopkins@hopkins-research.com) Received: from neon.webfusion.co.uk (neon.webfusion.co.uk [212.67.202.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACB6F43D46; Fri, 9 Sep 2005 11:16:29 +0000 (GMT) (envelope-from michael.hopkins@hopkins-research.com) Received: from 83-216-132-201.markch725.adsl.metronet.co.uk ([83.216.132.201] helo=[192.168.0.4]) by neon.webfusion.co.uk with asmtp (Exim 3.36 #1) id 1EDgpW-0006U2-00; Fri, 09 Sep 2005 12:14:02 +0100 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 09 Sep 2005 12:16:18 +0100 From: Michael Hopkins To: "freebsd-amd64@freebsd.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: AMD Core Math Library 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, 09 Sep 2005 11:16:30 -0000 Hi all I am wanting to link BLAS/LAPACK routines to the optimised libraries available from AMD (ACML 2.7) and Intel (MKL 7.2.1) and was wondering if anyone else had done this successfully or had any advice for me. I am currently using ATLAS and it works well but am considering distributing software to various different x86(_64) platforms without having to rebuild ATLAS in each case. There are three distinct build/link scenarios: 1) Natively on FreeBSD amd64 (using Athlon64/Opteron, hence ACML) 2) Cross-compiling to 32-bit Linux (Intel & AMD with /compat/linux/usr/bin/cc) 3) Cross-compiling to Win32 (Intel & AMD with /usr/local/mingw32/bin/cc) As both the libraries are intended for Linux, I am not sure of the implications for (1) & (3) - though the earlier replies to this thread seem to suggest no problem for (1) at least. Any tips on how to achieve this would be welcomed. Currently linking to ATLAS like this in all 3 scenarios: -L$(ATLASLIB) -llapack -lcblas -latlas TIA Michael _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/_/_/ Hopkins Research Ltd _/ _/ _/ _/ _/_/_/_/ _/_/_/ http://www.hopkins-research.com/ _/ _/ _/ _/ _/ _/ _/ _/ 'touch the future' _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From owner-freebsd-amd64@FreeBSD.ORG Fri Sep 9 14:57:19 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 4FBD816A41F for ; Fri, 9 Sep 2005 14:57:19 +0000 (GMT) (envelope-from fwuytack@fgscapital.com) Received: from mail.fgscapital.com (fw.fgscapital.com [82.110.72.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5367843D67 for ; Fri, 9 Sep 2005 14:57:11 +0000 (GMT) (envelope-from fwuytack@fgscapital.com) Received: (qmail 37190 invoked by uid 1003); 9 Sep 2005 14:57:08 -0000 Received: from fwuytack@fgscapital.com by mail.fgscapital.com by uid 89 with qmail-scanner-1.21 (clamdscan: 0.70-rc. spamassassin: 2.63. Clear:RC:1(192.168.0.106):. Processed in 0.099013 secs); 09 Sep 2005 14:57:08 -0000 Received: from unknown (HELO fgswksfilip) (fwuytack@fgscapital.com@192.168.0.106) by 192.168.110.115 with SMTP; 9 Sep 2005 14:57:08 -0000 From: "Filip Wuytack" To: , , Date: Fri, 9 Sep 2005 15:57:05 +0100 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcW1Tr0k87TL/RdFTrK1AeAidjGRTg== X-Qmail-Scanner-Message-ID: <112627782866137181@mail.fgscapital.com> Message-Id: <20050909145711.5367843D67@mx1.FreeBSD.org> Cc: Subject: Libtool1.5 fails on freebsd6.0-BETA4 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, 09 Sep 2005 14:57:19 -0000 # cd devel/libtool15 # make clean ===> Cleaning for libtool-1.5.20 # make ===> Vulnerability check disabled, database not found ===> Extracting for libtool-1.5.20 => Checksum OK for libtool-1.5.20.tar.gz. ===> Patching for libtool-1.5.20 ===> Applying FreeBSD patches for libtool-1.5.20 ===> Configuring for libtool-1.5.20 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking for gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of cc... none checking for a sed that does not truncate output... /usr/bin/sed checking build system type... amd64-portbld-freebsd6.0 checking host system type... amd64-portbld-freebsd6.0 checking for egrep... grep -E checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking dependency style of c++... none checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether f77 accepts -g... yes checking for gcj... no checking for windres... no checking for /usr/bin/ld option to reload object files... -r checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking how to run the C++ preprocessor... c++ -E checking the maximum length of command line arguments... (cached) 262144 checking command to parse /usr/bin/nm -B output from cc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if cc static flag works... yes checking if cc supports -fno-rtti -fno-exceptions... no checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... freebsd6.0 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by c++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes checking for c++ option to produce PIC... -fPIC checking if c++ PIC flag -fPIC works... yes checking if c++ supports -c -o file.o... yes checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... freebsd6.0 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for shl_load... (cached) no checking for shl_load in -ldld... (cached) no checking for dlopen... (cached) yes checking whether a program can dlopen itself... (cached) yes checking whether a statically linked program can dlopen itself... (cached) yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... freebsd6.0 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "GCJ" to libtool configure: creating ./config.status config.status: creating Makefile config.status: creating doc/Makefile config.status: creating tests/Makefile config.status: executing depfiles commands configure: configuring in libltdl configure: running /bin/sh './configure' --prefix=/usr/local '--disable-ltdl-install' '--program-suffix=15' '--prefix=/usr/local' '--build=amd64-portbld-freebsd6.0' 'CFLAGS=-O -pipe -march=opteron' 'CXX=c++' 'build_alias=amd64-portbld-freebsd6.0' 'CC=cc' 'CXXFLAGS=-O -pipe -march=opteron' --cache-file=/dev/null --srcdir=. checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... configure: error: newly created file is older than distributed files! Check your system clock configure: error: /bin/sh './configure' failed for libltdl ===> Script "configure" failed unexpectedly. Please report the problem to ade@FreeBSD.org [maintainer] and attach the "/usr/ports/devel/libtool15/work/libtool-1.5.20/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/devel/libtool15. ########################################################### Dmesg at boot ########################################################### 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-BETA4 #0: Wed Aug 10 13:55:54 BST 2005 fwuytack@bigbeast.fgsdomain.fgscapital.com:/usr/obj/usr/src/sys/FILIP WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Dual Core AMD Opteron(tm) Processor 275 (2193.77-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800,LM,3DNow+,3DNow> Hyperthreading: 2 logical CPUs real memory = 12884901888 (12288 MB) avail memory = 12401532928 (11827 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-27 on motherboard ioapic2 irqs 28-31 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 5 on acpi0 pci_link1: irq 9 on acpi0 pci_link2: irq 11 on acpi0 pci_link3: irq 10 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 6.0 on pci0 pci3: on pcib1 ohci0: mem 0xfeafc000-0xfeafcfff irq 19 at device 0.0 on pci3 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfeafd000-0xfeafdfff irq 19 at device 0.1 on pci3 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered atapci0: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xac00-0xac03,0xa880-0xa88f mem 0xfeafec00-0xfeafefff irq 19 at device 5.0 on pci3 ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 ata5: on atapci0 pci3: at device 6.0 (no driver attached) fxp0: port 0xa800-0xa83f mem 0xfeafb000-0xfeafbfff,0xfeaa0000-0xfeabffff irq 18 at device 8.0 on pci3 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:e0:81:30:7c:d5 isab0: at device 7.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 7.1 on pci0 ata0: on atapci1 ata1: on atapci1 pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) pcib2: at device 10.0 on pci0 pci2: on pcib2 ahd0: port 0x8000-0x80ff,0x7800-0x78ff mem 0xfc8fc000-0xfc8fdfff irq 24 at device 6.0 on pci2 ahd0: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs ahd1: port 0x8800-0x88ff,0x8400-0x84ff mem 0xfc8fe000-0xfc8fffff irq 25 at device 6.1 on pci2 ahd1: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs bge0: mem 0xfc8b0000-0xfc8bffff,0xfc8a0000-0xfc8affff irq 24 at device 9.0 on pci2 miibus1: on bge0 brgphy0: on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:e0:81:30:7d:1e bge1: mem 0xfc8e0000-0xfc8effff,0xfc8d0000-0xfc8dffff irq 25 at device 9.1 on pci2 miibus2: on bge1 brgphy1: on miibus2 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:e0:81:30:7d:1f pci0: at device 10.1 (no driver attached) pcib3: at device 11.0 on pci0 pci1: on pcib3 3ware device driver for 9000 series storage controllers, version: 3.60.00.017 twa0: <3ware 9000 series Storage Controller> port 0x6800-0x68ff mem 0xfc5ffc00-0xfc5ffcff,0xfb800000-0xfbffffff irq 28 at device 3.0 on pci1 twa0: [FAST] twa0: INFO: (0x04: 0x004e): Battery capacity test started: twa0: DEBUG: (0x04: 0x0054): Charge termination voltage is at high level: 0x0 twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue: twa0: INFO: (0x15: 0x1300): Controller details:: 12 ports, Firmware FE9X 2.04.00.005, BIOS BE9X 2.03.01.047 pci0: at device 11.1 (no driver attached) acpi_button0: on acpi0 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 Generic PS/2 mouse, device ID 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc97ff 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 Timecounters tick every 1.000 msec acd0: DVDROM at ata0-slave UDMA33 Waiting 5 seconds for SCSI devices to settle da0 at twa0 bus 0 target 0 lun 0 da0: <3ware Logical Disk 00 1.00> Fixed Direct Access SCSI-0 device da0: 100.000MB/s transfers da0: 762918MB (1562456064 512 byte sectors: 255H 63S/T 97258C) da1 at twa0 bus 0 target 1 lun 0 da1: <3ware Logical Disk 01 1.00> Fixed Direct Access SCSI-0 device da1: 100.000MB/s transfers da1: 1525836MB (3124912128 512 byte sectors: 255H 63S/T 194516C) SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Trying to mount root from ufs:/dev/da0s1a Regards, Filip begin 666 config.log M5&AI2!M97-S86=E2!C M;VUP:6QE2!'3E4@075T;V-O;F8@,BXU.2X@($EN=F]C871I;VX@ M8V]M;6%N9"!L:6YE('=A#TQ-2 M+7!R969I>#TO=7-R M+VQO8V%L("TM8G5I;&0]86UD-C0M<&]R=&)L9"UF71A8VM 8FEG M8F5A65S"F-O;F9I9W5R M93HQ-S4W.B!C:&5C:VEN9R!F;W(@9V%W:PIC;VYF:6=U65S"F-O;F9I9W5R93HR,#6EN9R!C;VYD:71I M;VYS+B @5&AE"!O9B!O8FIE8W0@9FEL97,*8V]N9FEG=7)E.C(U,S0Z(&-C("UC M("U/("UP:7!E("UM87)C:#UO<'1E65S"F-O M;F9I9W5R93HR-C(T.B!C:&5C:VEN9R!W:&5T:&5R(&-C(&%C8V5P=',@+6<* M8V]N9FEG=7)E.C(V-#4Z(&-C("UC("UG("!C;VYF=&5S="YC(#XF-0IC;VYF M:6=U6YT87@@ M97)R;W(@8F5F;W)E(")M92(*8V]N9FEG=7)E.C(X,C$Z("0_(#T@,0IC;VYF M:6=U6QE(&]F(&EN8VQU9&4@=7-E9"!B>2!M86ME"F-O;F9I M9W5R93HR.3DP.B!R97-U;'0Z($=.50IC;VYF:6=U2!S='EL92!O9B!C8PIC;VYF:6=U7-T96T@='EP90IC;VYF:6=U65S"F-O;F9I9W5R M93HS,S8P.B!C:&5C:VEN9R!F;W(@0E-$+6-O;7!A=&EB;&4@;FT*8V]N9FEG M=7)E.C,T,#(Z(')E65S"F-O;F9I9W5R93HS-3$T.B!C:&5C:VEN9R!F;W(@ M0RLK(&-O;7!I;&5R('9EB )"0D@?'P@=&5S=" A("US(&-O;F9T M97-T+F5R<@IC;VYF:6=U65S"F-O;F9I9W5R93HS M-C@V.B!C*RL@+6,@+4\@+7!I<&4@+6UA&ET)R!U;F1E8VQA2!O M;F-E(&9OB )"0D@?'P@=&5S=" A("US M(&-O;F9T97-T+F5R<@IC;VYF:6=UB )"0D@?'P@=&5S=" A("US(&-O M;F9T97-T+F5R<@IC;VYF:6=U2!S='EL92!O M9B!C*RL*8V]N9FEG=7)E.C,X-C,Z(')E7)I9VAT("A#*2 R,# T($9R964@ M4V]F='=A6EN9R65S"F-O;F9I9W5R93HT,#8R.B!C:&5C:VEN9R!W:&5T:&5R(&8W-R!A M8V-E<'1S("UG"F-O;F9I9W5R93HT,#B )"0D@?'P@=&5S=" A("US(&-O;F9T97-T+F5R<@IC;VYF:6=U M&ES=&5N M="YH.B!.;R!S=6-H(&9I;&4@;W(@9&ER96-T;W)Y"F-O;F9I9W5R93HU,C0X M.B D/R ](#$*8V]N9FEG=7)E.B!F86EL960@<')O9W)A;2!W87,Z"GP@+RH@ M8V]N9F1E9G,N:"X@("HO"GP@"GP@(V1E9FEN92!004-+04=%7TY!344@(FQI M8G1O;VPQ-2(*?" C9&5F:6YE(%!!0TM!1T5?5$%23D%-12 B;&EB=&]O;#$U M(@I\("-D969I;F4@4$%#2T%'15]615)324].("(Q+C4N,C B"GP@(V1E9FEN M92!004-+04=%7U-44DE.1R B;&EB=&]O;" Q+C4N,C B"GP@(V1E9FEN92!0 M04-+04=%7T)51U)%4$]25" B8G5G+6QI8G1O;VQ 9VYU+F]R9R(*?" C9&5F M:6YE(%!!0TM!1T4@(FQI8G1O;VPQ-2(*?" C9&5F:6YE(%9%4E-)3TX@(C$N M-2XR,"(*?" C:69D968@7U]C<&QU'1E&ET("AI;G0I('1H&ES=&5N="YH/@IC;VYF:6=U65S"F-O;F9I9W5R93HU-#B )"0D@?'P@=&5S=" A("US(&-O;F9T97-T+F5R<@IC M;VYF:6=U65S"F-O;F9I9W5R93HU M-#65S"F-O;F9I9W5R93HU-#65S"F-O;F9I M9W5R93HU-#B )"0D@?'P@=&5S=" A("US(&-O;F9T M97-T+F5R<@IC;VYF:6=UB ) M"0D@?'P@=&5S=" A("US(&-O;F9T97-T+F5R<@IC;VYF:6=U65S"F-O;F9I M9W5R93HU-C4W.B!C:&5C:VEN9R!F;W(@9&QF8VXN: IC;VYF:6=U0IC;VYF:6=U&ES=&5N="YH.B!.;R!S M=6-H(&9I;&4@;W(@9&ER96-T;W)Y"F-O;F9I9W5R93HU.#8Y.B D/R ](#$* M8V]N9FEG=7)E.B!F86EL960@<')O9W)A;2!W87,Z"GP@+RH@8V]N9F1E9G,N M:"X@("HO"GP@"GP@(V1E9FEN92!004-+04=%7TY!344@(FQI8G1O;VPQ-2(* M?" C9&5F:6YE(%!!0TM!1T5?5$%23D%-12 B;&EB=&]O;#$U(@I\("-D969I M;F4@4$%#2T%'15]615)324].("(Q+C4N,C B"GP@(V1E9FEN92!004-+04=% M7U-44DE.1R B;&EB=&]O;" Q+C4N,C B"GP@(V1E9FEN92!004-+04=%7T)5 M1U)%4$]25" B8G5G+6QI8G1O;VQ 9VYU+F]R9R(*?" C9&5F:6YE(%!!0TM! M1T4@(FQI8G1O;VPQ-2(*?" C9&5F:6YE(%9%4E-)3TX@(C$N-2XR,"(*?" C M:69D968@7U]C<&QU'1E&ET M("AI;G0I('1H65S"F-O;F9I9W5R93HV.#4U.B!C:&5C:VEN M9R!I9B!C8R!S=7!P;W)T&-E<'1I;VYS"F-O M;F9I9W5R93HV.#65S"F-O;F9I9W5R93HW,365S"F-O;F9I9W5R93HX,38Y.B!C:&5C:VEN9R!W:&5T M:&5R("UL8R!S:&]U;&0@8F4@97AP;&EC:71L>2!L:6YK960@:6X*8V]N9FEG M=7)E.C@Q-S0Z(&-C("UC("U/("UP:7!E("UM87)C:#UO<'1E2!P871H#2X@("HO"GP@(V1E9FEN M92!S:&Q?;&]A9"!I;FYO8W5O=7-?7-T96T@ M:&5A9&5R('1O(&1E9FEN92!?7W-T=6(@;6%C7!E('1O(&%V;VED(&%N M(&5R'1EPI\("-E;F1I9@I\("\J(%=E('5S92!C:&%R(&)E8V%U7,@9F%I;"!W:71H($5.3U-9 M4RX@(%-O;64@9G5N8W1I;VYS(&%R92!A8W1U86QL>2!N86UE9 I\(" @("!S M;VUE=&AI;F<@2!G8V,R(&EN=&5R;F%L('!R;W1O='EP92!T M;R!A=F]I9"!A;B!E2!C*RL*8V]N9FEG=7)E.C$P-# Y.B!R97-U;'0Z("]U65S"F-O;F9I9W5R93HQ,#0X-#H@8VAE8VMI;F<@=VAE=&AE65S"F-O;F9I9W5R93HQ M,3@S,CH@8VAE8VMI;F<@:68@8RLK('-U<'!O6YA;6EC(&QI;FME2!P M871H65S"F-O M;F9I9W5R93HQ,S(Q,CH@8VAE8VMI;F<@=VAE=&AE65S"F-O;F9I9W5R93HQ,SDV,#H@8VAE8VMI;F<@ M=VAE=&AE6YA M;6EC(&QI;FME2!P871H2!'3E4@075T;V-O;F8@,BXU M.2X@($EN=F]C871I;VX@8V]M;6%N9"!L:6YE('=A#TO M=7-R+VQO8V%L(" G+2UD:7-A8FQE+6QT9&PM:6YS=&%L;"<@)RTM<')O9W)A M;2US=69F:7@],34G("#TO=7-R+VQO8V%L)R G+2UB=6EL9#UA M;60V-"UP;W)T8FQD+69R965B7-?9VQO8F%L7W-Y;6)O;%]P:7!E/27!E/6YO;F4*86-?8W9? M<')O9U]#6%A#4% ])V,K*R M12<*86-?8W9?96YV7T-86$9,04=37W9A;'5E M/26UB;VQ?=&]?8V1E8VP])W-E9" M;B M92 G7"+B N*B!<*"XJ7"DD M+V5X=&5R;B!I;G0@7#$[+W G7"65S"FQT7V-V7V9I;&5?;6%G:6-?8VUD/2#UY97,*86-?8W9?9G5N8U]D;&]P96X]>65S"F%C M7V-V7W!R;V=?8V-?9SUY97,*86-?8W9?96YV7T-86$-04%]S970]"F%C7V-V M7V5N=E],1$9,04=37W-E=#T*;'1?8W9?<')O9U]C;VUP:6QE65S"F%C7V-V7V5X965X=#T* M86-?8W9?96YV7T-&3$%'4U]S970]65S"FQT7V-V7V1L;W!E M;E]L:6)S/0IA8U]C=E]C>'A?8V]M<&EL97)?9VYU/7EE65S(B<*86-?8W9?96YV7VAO7-? M9VQO8F%L7W-Y;6)O;%]T;U]C7VYA;65?861D.B!<7"A;7B!=*EQ<*2!<)"\@('M<7%PB7%PQ7%Q<(BP@*&QT7W!T M(%TJ7%PI M(%Q<*%M>(%TJ7%PI7"0O("![7")<7#)<(BP@*&QT7W!T65S"FQT7V-V7VQD M7W)E;&]A9%]F;&%G/2UR"FQT7V-V7W!R;V=?9VYU7VQD/7EE65S"F%C7V-V7VAE861E7-?='EP97-?:#UY97,*86-?8W9?:&5A M9&5R7W-T9&,]>65S"F%C7V-V7VAE861E65S"FQT7V-V M7W!A=&A?4T5$/2]U65S"F%C7V-V7VAE861E7!E65S"F%C M7V-V7V5N=E]&1DQ!1U-?=F%L=64]"FQT7V-V7W!A=&A?3$0]+W5S%]G/7EE M+BI;( E=7"A;04)#1$=)4E-4 M5UU;04)#1$=)4E-45UTJ7"E;( E=6R )72I<*%M?02U:82UZ75M?02U:82UZ M,"TY72I<*20O7#$@7#(@7#(O<"=<)R'0];PH*(R,@+2TM+2TM+2TM+2TM M+2TM+2T@(R,*(R,@3W5T<'5T('9AU-(14Q,?2 O=7-R+W!OT%-5$%2?2!C:&]F("T@(B0D M=&%R9&ER(B<*86U?7W5N=&%R/2T%-5$%2?2!X9B M)PIB:6YD:7(])R1[ M97AE8U]P&5C7W!R969I>#TG)'MP&5C M7W!R969I>'TO;&EB)PIL:6)E>&5C9&ER/2V5X96-?<')E9FEX?2]L:6)E M>&5C)PIL;V-A;'-T871E9&ER/2W!R969I>'TO=F%R)PIM86YD:7(])R1[ M<')E9FEX?2]M86XG"FUK9&ER7W ])R0H:6YS=&%L;%]S:"D@+60G"F]L9&EN M8VQU9&5D:7(])R]U#TG+W5SW!R969I>'TO8V]M)PIS=6)D:7)S M/2<@;&EB;'1D;"<* 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 224ED16A41F; Fri, 9 Sep 2005 15:07:36 +0000 (GMT) (envelope-from ade@lovett.com) Received: from mail.lovett.com (foo.lovett.com [67.134.38.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3A5443D46; Fri, 9 Sep 2005 15:07:35 +0000 (GMT) (envelope-from ade@lovett.com) Received: from hellfire.lab.lovett.com ([192.168.32.20]:49479) by mail.lovett.com with esmtpa (Exim 4.52 (FreeBSD)) id 1EDkTX-0000iw-CW; Fri, 09 Sep 2005 08:07:35 -0700 In-Reply-To: <20050909145711.99E7943D64@mx1.FreeBSD.org> References: <20050909145711.99E7943D64@mx1.FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <02F8BF96-5E2F-4C08-8835-434196FF2266@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Ade Lovett Date: Fri, 9 Sep 2005 08:07:34 -0700 To: Filip Wuytack X-Mailer: Apple Mail (2.734) Sender: ade@lovett.com X-SA-Exim-Connect-IP: 192.168.32.20 X-SA-Exim-Mail-From: ade@lovett.com X-SA-Exim-Scanned: No (on mail.lovett.com); SAEximRunCond expanded to false Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Libtool1.5 fails on freebsd6.0-BETA4 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, 09 Sep 2005 15:07:36 -0000 On Sep 09, 2005, at 07:57 , Filip Wuytack wrote: > [snip] > > checking whether build environment is sane... configure: error: newly > created file is older than distributed files! > Check your system clock > configure: error: /bin/sh './configure' failed for libltdl Please do try to read the error messages produced by scripts. Thanks awfully. -aDe From owner-freebsd-amd64@FreeBSD.ORG Fri Sep 9 16:27:41 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 7050A16A41F for ; Fri, 9 Sep 2005 16:27:41 +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 2388B43D49 for ; Fri, 9 Sep 2005 16:27:36 +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 j89GRaBG001535; Fri, 9 Sep 2005 09:27:36 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j89GRZT5001534; Fri, 9 Sep 2005 09:27:35 -0700 (PDT) (envelope-from obrien) Date: Fri, 9 Sep 2005 09:27:35 -0700 From: "David O'Brien" To: Michael Hopkins Message-ID: <20050909162735.GA1493@dragon.NUXI.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 7.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: AMD Core Math Library 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, 09 Sep 2005 16:27:41 -0000 On Fri, Sep 09, 2005 at 12:16:18PM +0100, Michael Hopkins wrote: > I am wanting to link BLAS/LAPACK routines to the optimised libraries > available from AMD (ACML 2.7) and Intel (MKL 7.2.1) and was wondering if > anyone else had done this successfully or had any advice for me. ... > There are three distinct build/link scenarios: > 1) Natively on FreeBSD amd64 (using Athlon64/Opteron, hence ACML) > 2) Cross-compiling to 32-bit Linux (Intel & AMD with > /compat/linux/usr/bin/cc) > 3) Cross-compiling to Win32 (Intel & AMD with /usr/local/mingw32/bin/cc) mingw32 produces fully native PE Win32 applications vs. cygwin, correct? So you'll need the Win32 version of ACML to do this. I don't recall if there is one, but if so it should "just work" in this cross build environment. > As both the libraries are intended for Linux, I am not sure of the > implications for (1) & (3) - though the earlier replies to this thread seem > to suggest no problem for (1) at least. I've done (1) with no problems. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Sat Sep 10 17:08:55 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 8252716A41F; Sat, 10 Sep 2005 17:08:55 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92CAC43D45; Sat, 10 Sep 2005 17:08:52 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.13.4/8.13.4/Debian-3) with ESMTP id j8AH8oW6023061; Sat, 10 Sep 2005 19:08:50 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id j8AH8oeY023059; Sat, 10 Sep 2005 19:08:50 +0200 Received: from saturn.kn-bremen.de (localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.1/8.13.1) with ESMTP id j8AH6MxK033953; Sat, 10 Sep 2005 19:06:22 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.1/8.13.1/Submit) id j8AH6MpH033952; Sat, 10 Sep 2005 19:06:22 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 10 Sep 2005 19:06:22 +0200 To: qemu-devel@nongnu.org, freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org Message-ID: <20050910170622.GA33797@saturn.kn-bremen.de> Mail-Followup-To: qemu-devel@nongnu.org, freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org References: <20050906190753.GA8560@saturn.kn-bremen.de> <20050906195449.GA10388@saturn.kn-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050906195449.GA10388@saturn.kn-bremen.de> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: oops! (was: FreeBSD qemu port update - some success with kqemu/amd64 :) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2005 17:08:55 -0000 On Tue, Sep 06, 2005 at 09:54:49PM +0200, Juergen Lock wrote: > Jung-uk Kim just made me aware of a device cloning change which requires > a patch to the kqemu wrapper for __FreeBSD_version >= 600034. So here > is a new port update: >[...] Ok I have send-pr'd now (updated to 20050909 snapshot because that contains a div64 fix which fixes ssh): http://www.freebsd.org/cgi/query-pr.cgi?pr=85947 As always, use the Raw PR link at the bottom of the page if you want to manually apply it to your ports tree... Juergen From owner-freebsd-amd64@FreeBSD.ORG Sat Sep 10 17:20:18 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 777F416A41F; Sat, 10 Sep 2005 17:20:18 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84A9243D45; Sat, 10 Sep 2005 17:20:16 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.13.4/8.13.4/Debian-3) with ESMTP id j8AHKFFl023615; Sat, 10 Sep 2005 19:20:15 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id j8AHKFWL023613; Sat, 10 Sep 2005 19:20:15 +0200 Received: from saturn.kn-bremen.de (localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.1/8.13.1) with ESMTP id j8AHJdeD034207; Sat, 10 Sep 2005 19:19:39 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.1/8.13.1/Submit) id j8AHJdl4034206; Sat, 10 Sep 2005 19:19:39 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 10 Sep 2005 19:19:39 +0200 To: qemu-devel@nongnu.org, freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org Message-ID: <20050910171939.GA34190@saturn.kn-bremen.de> Mail-Followup-To: qemu-devel@nongnu.org, freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org References: <20050906190753.GA8560@saturn.kn-bremen.de> <20050906195449.GA10388@saturn.kn-bremen.de> <20050910170622.GA33797@saturn.kn-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050910170622.GA33797@saturn.kn-bremen.de> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: oops! (was: FreeBSD qemu port update - some success with kqemu/amd64 :) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2005 17:20:18 -0000 On Sat, Sep 10, 2005 at 07:06:22PM +0200, Juergen Lock wrote: > On Tue, Sep 06, 2005 at 09:54:49PM +0200, Juergen Lock wrote: > > Jung-uk Kim just made me aware of a device cloning change which requires > > a patch to the kqemu wrapper for __FreeBSD_version >= 600034. So here > > is a new port update: > >[...] > > Ok I have send-pr'd now (updated to 20050909 snapshot because that > contains a div64 fix which fixes ssh): > http://www.freebsd.org/cgi/query-pr.cgi?pr=85947 > > As always, use the Raw PR link at the bottom of the page if you want > to manually apply it to your ports tree... Already committed... Hey, i think this is the fastest commit i have ever seen! :) Thanx, Juergen From owner-freebsd-amd64@FreeBSD.ORG Sat Sep 10 23:03:38 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 9A2CB16A41F for ; Sat, 10 Sep 2005 23:03:38 +0000 (GMT) (envelope-from mi@blue.virtual-estates.net) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC31843D53 for ; Sat, 10 Sep 2005 23:03:37 +0000 (GMT) (envelope-from mi@blue.virtual-estates.net) Received: (qmail 977 invoked from network); 10 Sep 2005 23:03:37 -0000 Received: from aldan.algebra.com (HELO blue.virtual-estates.net) ([216.254.65.224]) (envelope-sender ) by mail28.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 Sep 2005 23:03:37 -0000 Received: from blue.virtual-estates.net (blue [127.0.0.1]) by blue.virtual-estates.net (8.13.3/8.13.3) with ESMTP id j8AN3ZcV073022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Sep 2005 19:03:35 -0400 (EDT) (envelope-from mi@blue.virtual-estates.net) Received: (from mi@localhost) by blue.virtual-estates.net (8.13.4/8.13.3/Submit) id j8AN3ZO9073021; Sat, 10 Sep 2005 19:03:35 -0400 (EDT) (envelope-from mi) From: "Mikhail T." Message-Id: <200509102303.j8AN3ZO9073021@blue.virtual-estates.net> To: amd64@FreeBSD.org, current@FreeBSD.org Date: Sat, 10 Sep 2005 19:03:35 -0400 (EDT) X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2005 23:03:38 -0000 Hello! I built and installed audio/timidity the stock compiler with my usual CFLAGS: -O2 -fno-strict-aliasing -pipe -march=opteron It dies on startup from SIGFPE. I turned on "-Wall -Werror" and patched the port to compile cleanly without any warning. That did not help... Compiling with -O1 or -O0 is fine. I remember having the same issue with Tcl84 compiled with -O2 -- what's wrong with the second level of optimization? Is not it supposed to finally work? I'm using 5.4-stable from July 21 on amd64. Please, advise. Thanks! -mi