From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 19 11:08:36 2007 Return-Path: X-Original-To: freebsd-sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 854E216A407 for ; Mon, 19 Feb 2007 11:08:36 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 73F9413C48D for ; Mon, 19 Feb 2007 11:08:36 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l1JB8a6s021491 for ; Mon, 19 Feb 2007 11:08:36 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l1JB8ZoN021487 for freebsd-sparc64@FreeBSD.org; Mon, 19 Feb 2007 11:08:35 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Feb 2007 11:08:35 GMT Message-Id: <200702191108.l1JB8ZoN021487@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 11:08:36 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC o sparc/72962 sparc64 [sysinstall] Sysinstall panics on sparc64 if /dev/cd0 o sparc/80410 sparc64 [netgraph] netgraph is causing crash with mpd on sparc o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/91882 sparc64 [mouse] Ultra 10 mouse/keyboard o sparc/92033 sparc64 [dc] dc(4) issues on Ultra10 o sparc/95297 sparc64 vt100 term does not work in install o sparc/95892 sparc64 [hme] MAC address of hme interfaces is ff:ff:ff:ff:ff: o sparc/98269 sparc64 Fresh 6.1 installation fails to boot o sparc/104428 sparc64 nullfs panics on E4500 (but not E420) o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/105607 sparc64 ipfw on sparc64 doesn't work at all (causes panic) o sparc/106251 sparc64 malloc fails > for large allocations s sparc/107087 sparc64 system is hinged during boot from CD o sparc/107947 sparc64 mysqld periodically core dumps (signal 4) with libthr 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/72998 sparc64 [kernel] [patch] set_mcontext() change syscalls parame f sparc/91334 sparc64 FreeBSD 6.0 don't support tftp boot from remot tftp se o sparc/94190 sparc64 hw.physmem tunable does not work on sparc o sparc/94483 sparc64 [ath] ath_hal does not work on 6-release/sparc64 o sparc/97707 sparc64 mkskel.sh has bogus timestamp, causing buildworld on s o sparc/105157 sparc64 No reply to ping on Sparc64 o sparc/108732 sparc64 ping reports 14 digit time o sparc/108757 sparc64 cant boot if rtc stuffed, no means of recovery 8 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 19 12:50:51 2007 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2C7B16A402 for ; Mon, 19 Feb 2007 12:50:51 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mx2.netclusive.de (mx2.netclusive.de [89.110.132.132]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5B113C474 for ; Mon, 19 Feb 2007 12:50:50 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (Fdc9f.f.ppp-pool.de [195.4.220.159]) by mx2.netclusive.de (Postfix) with ESMTP id F03A5260097 for ; Mon, 19 Feb 2007 13:50:47 +0100 (CET) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id 1331E1521B; Mon, 19 Feb 2007 13:50:46 +0100 (CET) To: freebsd-sparc64@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.sparc Date: Mon, 19 Feb 2007 13:50:46 +0100 (CET) Organization: Convenimus Projekt Lines: 31 Message-ID: References: <45C9430B.5020402@alaska.net> NNTP-Posting-Host: garfield.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1171889446 27498 192.168.100.11 (19 Feb 2007 12:50:46 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Mon, 19 Feb 2007 12:50:46 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD) Subject: Re: freebsd-update/sparc64 and buildworld statistics X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 12:50:51 -0000 On Tue, 06 Feb 2007 18:10:03 -0900 Royce Williams wrote: > cperciva told me recently that he could start building the patches for > freebsd-update for sparc64 today -- if he had access to a Sun with > enough oomph to buildworld in under an hour. Is there such a thing? AFAIK FreeBSD (as any on the BSDs) currently only support UltraSPARC I and II processors which means no more than 450MHz. You would need quite a few of those to reach that goal, although I doubt that it could really be done at all just by using more processors as the building of the world partially has to be done step by step. You can't just start anywhere, some things have to be finished before others can be done. > Is anyone interested in tracking buildworld times for various FreeBSD > versions and architectures? Now that wiki.FreeBSD.org is in > production, maybe it could go there -- or we could keep it elsewhere. Well, I'll let you decide where to put the first few benchmarks. :-) I got this on my system with '/usr/bin/time -h': 2h58m19.87s real 4h53m45.89s user 47m42.77s sys The command was 'make -j 4 buildworld'. Compiler flags were the default. The system is a U60 with 2 450MHz UltraSPARC II processors (no 'e' or 'i'), 2GB of mem and two 73GB Seagate Cheetah HDs with /usr and /usr/obj mounted on different physical drives. Regards Chris From owner-freebsd-sparc64@FreeBSD.ORG Tue Feb 20 07:19:51 2007 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 127D0173DC7 for ; Tue, 20 Feb 2007 07:19:51 +0000 (UTC) (envelope-from royce@alaska.net) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.173.229]) by mx1.freebsd.org (Postfix) with ESMTP id D5A0613C442 for ; Tue, 20 Feb 2007 07:19:50 +0000 (UTC) (envelope-from royce@alaska.net) Received: from [192.168.254.100] (209-112-136-196-cdsl-rb1.nwc.acsalaska.net [209.112.136.196]) by iris.acsalaska.net (8.13.8/8.13.8) with ESMTP id l1K7Jn7W056807; Mon, 19 Feb 2007 22:19:49 -0900 (AKST) (envelope-from royce@alaska.net) Message-ID: <45DAA11E.5020704@alaska.net> Date: Mon, 19 Feb 2007 22:19:58 -0900 From: Royce Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Christian Baer References: <45C9430B.5020402@alaska.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.57; SA 3.1.6; spamdefang 1.118 Cc: freebsd-sparc64@freebsd.org Subject: Re: freebsd-update/sparc64 and buildworld statistics X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 07:19:51 -0000 Christian Baer wrote, on 2/19/2007 3:50 AM: > On Tue, 06 Feb 2007 18:10:03 -0900 Royce Williams wrote: > >> cperciva told me recently that he could start building the patches for >> freebsd-update for sparc64 today -- if he had access to a Sun with >> enough oomph to buildworld in under an hour. > > Is there such a thing? AFAIK FreeBSD (as any on the BSDs) currently only > support UltraSPARC I and II processors which means no more than 450MHz. > You would need quite a few of those to reach that goal, although I doubt > that it could really be done at all just by using more processors as the > building of the world partially has to be done step by step. You can't > just start anywhere, some things have to be finished before others can > be done. It may be that there's no way to break that 1-hour barrier. Maybe I can convince Colin that, until full cross-compiling is available, we sparc64 folks would settle for slightly-delayed binary security updates (instead of never getting them at all). It's the very fact that we're running on slower hardware that makes freebsd-update so attractive. I'd still like to see what a quad Ultra 80 can do, though. :) Who has access to one of these? Chris, did you do any of the other things that the handbook 'Rebuilding "world"' section suggests -- noatime /usr/src, async /usr/obj, etc? Also, are you tracking 6.2-STABLE, -RELEASE, or something else? If -STABLE, as of when? Over time, these data points may be relevant. >> Is anyone interested in tracking buildworld times for various FreeBSD >> versions and architectures? Now that wiki.FreeBSD.org is in >> production, maybe it could go there -- or we could keep it elsewhere. > > Well, I'll let you decide where to put the first few benchmarks. :-) This'll do until we come up with something better: http://www.alaska.net/~royce/freebsd/sparc64/worldstone/ Thanks! Royce -- FreeBSD - The SPARC to Serve http://www.alaska.net/~royce/freebsd/sparc64/ From owner-freebsd-sparc64@FreeBSD.ORG Tue Feb 20 17:15:46 2007 Return-Path: X-Original-To: freebsd-sparc@freebsd.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 175E116B74D for ; Tue, 20 Feb 2007 17:15:46 +0000 (UTC) (envelope-from dbrewer@pixelfish.com) Received: from mail01.vmatrixmail.com (mail01.vmatrixmail.com [216.219.244.230]) by mx1.freebsd.org (Postfix) with ESMTP id ADBCF13C4AC for ; Tue, 20 Feb 2007 17:15:44 +0000 (UTC) (envelope-from dbrewer@pixelfish.com) Received: (vmatrix@mail01.vmatrixmail.com) by vmatrixmail.com id S6072532AbXBTQpv for ; Tue, 20 Feb 2007 08:45:51 -0800 To: freebsd-sparc@freebsd.org MIME-Version: 1.0 X-Mailer: Rich Media Mail V4. Vmatrix, (C) 2003 From: "David Brewer" Sender: "David Brewer" Message-Id: Date: Tue, 20 Feb 2007 08:45:51 -0800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Your Recent Trade Show Results X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbrewer@pixelfish.com List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 17:15:46 -0000 Greetings!

Are you happy with your results from Social Linux Expo 2007? Did you have what it takes to make the difference between creating excitement and blending in with the competition, between lots of hot leads and a few hard sells ... between success and failure?

Did you have video?

Why video? Video vividly demonstrates the features and benefits of your products. Video captures the praises of your most enthusiastic customers. Video instills interest, reaction and trust. Video sells.

In just 45 days, PixelFish creates marketing videos that become an integral part of your marketing and sales efforts when it streams from your Web site, launches from multimedia email newsletters, plays from CD video brochures and loops from a DVD at your tradeshow booth.

We are PixelFish. We deliver “The Evolution of Video”. And we guarantee results. Click on the videos to the right to see samples of our work.

Contact us today for a free evaluation of your video marketing needs.

David Brewer
PixelFish, Inc.
800.503.3020 x102
dbrewer@pixelfish.com
http://www.pixelfish.com
RedMan Video
Pentax Video
JEM Video
------------------------------------------------ Unsubscribe to safely remove yourself from this email list, please send email to info@pixelfish.com. Powered by Pixelfish http://www.pixelfish.com From owner-freebsd-sparc64@FreeBSD.ORG Wed Feb 21 11:50:39 2007 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD88C16A658 for ; Wed, 21 Feb 2007 11:50:39 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mx1.netclusive.de (mx1.netclusive.de [89.110.132.131]) by mx1.freebsd.org (Postfix) with ESMTP id 5634413C442 for ; Wed, 21 Feb 2007 11:50:39 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (Fdd6e.f.ppp-pool.de [195.4.221.110]) by mx1.netclusive.de (Postfix) with ESMTP id 6ACABDE806D for ; Wed, 21 Feb 2007 12:50:35 +0100 (CET) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id 78FA61521B; Wed, 21 Feb 2007 12:50:34 +0100 (CET) To: freebsd-sparc64@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.sparc Date: Wed, 21 Feb 2007 12:50:34 +0100 (CET) Organization: Convenimus Projekt Lines: 72 Message-ID: References: <45C9430B.5020402@alaska.net> <45DAA11E.5020704@alaska.net> NNTP-Posting-Host: garfield.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1172058634 39351 192.168.100.11 (21 Feb 2007 11:50:34 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Wed, 21 Feb 2007 11:50:34 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD) Subject: Re: freebsd-update/sparc64 and buildworld statistics X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 11:50:39 -0000 On Mon, 19 Feb 2007 22:19:58 -0900 Royce Williams wrote: > It may be that there's no way to break that 1-hour barrier. Maybe I > can convince Colin that, until full cross-compiling is available, we > sparc64 folks would settle for slightly-delayed binary security > updates (instead of never getting them at all). It's the very fact > that we're running on slower hardware that makes freebsd-update so > attractive. Actually, I thought cross compiling already worked. The only thing that was missing is the documentation and some make files??? Currently I'm not having much trouble working with the source updates. Ok, basicly they suck because compiling takes a pretty long time. But on my U60 I can start the process when I go to bed and it's done in the morning. People using a U1E (or anything else that slow) will probably have to wait a whole day or even more. On the bright side, people using a U1 unter FreeBSD *probably* won't bei using it as a prodction system, so they will have a little more time for compiling. > I'd still like to see what a quad Ultra 80 can do, though. :) Who has > access to one of these? When I win the lottery. :-) > Chris, did you do any of the other things that the handbook > 'Rebuilding "world"' section suggests -- noatime /usr/src, async > /usr/obj, etc? Also, are you tracking 6.2-STABLE, -RELEASE, or > something else? If -STABLE, as of when? Over time, these data points > may be relevant. Not all of the suggestions... /usr and /usr/obj are seperate file systems on different physical drives (as I have already written). /usr/obj is mounted async. Since this system is also an experiment for me the access times of file may be useful if something goes wrong. And since /usr/src is not a seperate file system but a small part of /usr, I wanted to keep that on. I don't think these option will do much for the speed of making a new world on my machine though. Increasing the throughput of the HDs is a good idea if the CPU can deliver the information faster than the HDs can read or write them (as an AMD64 or Core2 Duo could). In our case, I doubt that the HDs will be the bottle neck, but the limited CPU power. Both of the CPUs in my U60 show 100% usage almost all of the time. And since this is a SCSI-system, HD-operation doesn't make the CPU work much harder either. The tag for the cvsup ist RELENG_6. This system started out with 6.1-RELEASE and I went from there. I can't tell you how much time has passed since I did the last buildworld. But it shouldn't make much difference anyway as the whole system is built from scratch anyway. uname -a spits this out: FreeBSD sunny.rz1.convenimus.net 6.2-STABLE FreeBSD 6.2-STABLE #0: Mon Feb 19 21:33:40 CET 2007 root@sunny.rz1.convenimus.net:/usr/obj/usr/src/sys/SUNNY sparc64 >> Well, I'll let you decide where to put the first few benchmarks. :-) > > This'll do until we come up with something better: > http://www.alaska.net/~royce/freebsd/sparc64/worldstone/ At times I am having problems connecting to alaska.net. Maybe we should get a mirror in Europe. :-) > Thanks! No problem! Regards Chris From owner-freebsd-sparc64@FreeBSD.ORG Wed Feb 21 21:58:49 2007 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 836B416A403 for ; Wed, 21 Feb 2007 21:58:49 +0000 (UTC) (envelope-from evultrole@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 1E51613C4A7 for ; Wed, 21 Feb 2007 21:58:48 +0000 (UTC) (envelope-from evultrole@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so1036760ugh for ; Wed, 21 Feb 2007 13:58:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=q0GrqZaSTxeRpvjnFzDQtGKo+vJ7kw9frU44x7Eq3roVlZNxbDRPzPOcrH7bmWZmwEh2qGtHovPqt8Uft1tlwhf2rcliwNhfv4B/cwkYWa2/dwLeZzFNQzaqBVkLe5SzZHxQKbWJMhXmssx5WogOKO0Dr7xbWgIolDsnBtyRJF8= Received: by 10.78.50.5 with SMTP id x5mr1413444hux.1172095127819; Wed, 21 Feb 2007 13:58:47 -0800 (PST) Received: by 10.78.178.6 with HTTP; Wed, 21 Feb 2007 13:58:47 -0800 (PST) Message-ID: <340594530702211358g37430181nf783803ad41f14de@mail.gmail.com> Date: Wed, 21 Feb 2007 13:58:47 -0800 From: "Steven Hillis" To: freebsd-sparc64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: good (working) CFLAGS for SPARC64 (Christian Baer) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 21:58:49 -0000 Christian, Apologies for the confusion, I gave you working tags from memory, not my make.conf file (i've been jockeying back and forth between a FreeBSD and a gentoo box, and use the same tags on them both, -mcpu on gentoo, -mtune on freebsd). FreeBSD sparc64 only supports ultrasparc and ultrasparcII cpus, so far as I know, so -mcpu=ultrasparc is superfluous. I in fact have -mtune=ultrasparc, since they likely use the v9 standard for FreeBSD since they seem to be attempting Ultrasparc III support. Again, I'm sorry about my bad memory. -mcpu=ultrasparc and -m64 should both be useless options under Sparc64, as far as I can tell. My actual make.conf file is as follows: CFLAGS=-O2 -pipe -mtune=ultrasparc -mvis -mapp-regs -fomit-frame-pointer -ffast-math -fweb -frename-registers COPTFLAGS=-O2 -pipe -mtune=ultrasparc -mvis -mapp-regs -fomit-frame-pointer -ffast-math -fweb -frename-registers NO_MODULES=YES NO_PROFILE=YES .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && !defined(NOCCACHE) CC=/usr/local/libexec/ccache/world-cc CXX=/usr/local/libexec/ccache/world-c++ .endif Those flags compile without a hitch. Again, Sparc64 is only for ultrasparc CPUs, so that's not really needed. The question is (this is aimed at Marius, et al), why does setting the -mcpu flag unset the __sparc64__ definition in so many places? This is what your errors came from, there are about 20 files that will do that. ~Steven From owner-freebsd-sparc64@FreeBSD.ORG Wed Feb 21 22:16:31 2007 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C101116A401 for ; Wed, 21 Feb 2007 22:16:31 +0000 (UTC) (envelope-from evultrole@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 4948413C471 for ; Wed, 21 Feb 2007 22:16:31 +0000 (UTC) (envelope-from evultrole@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so1040756ugh for ; Wed, 21 Feb 2007 14:16:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=n7ZfPezO8mSmKZTx9vgd81tvXICKFtPB7nopLFYLMMWmVVC7pPsfX9s/QMFsZIrUOZ4BO6CQXbmmgHQARfltelZiCdgckp+FKLPn7L0SNpi5kYq9Rij3l40KsNqkKFqnGLERdLpSW5rtOUYhjQXvxi4uMiwiSSrHQAA2wut9MzI= Received: by 10.78.201.2 with SMTP id y2mr1414442huf.1172096189928; Wed, 21 Feb 2007 14:16:29 -0800 (PST) Received: by 10.78.178.6 with HTTP; Wed, 21 Feb 2007 14:16:29 -0800 (PST) Message-ID: <340594530702211416l1a9d03k8051fc5d685f841b@mail.gmail.com> Date: Wed, 21 Feb 2007 14:16:29 -0800 From: "Steven Hillis" To: freebsd-sparc64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: freebsd-update/sparc64 and buildworld statistics X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 22:16:31 -0000 >I'd still like to see what a quad Ultra 80 can do, though. :) Who has access to one of these? I have one of these under my foot right now. 4x450 4GB memory, 2xScsi drives. I went ahead a did a fresh install to get rid of all the weird things I customized, added back only noatime and async. I also rebuilt the world using the CFLAGS I listed in the last e-mail I sent out, updated, then cleaned out the src tree, put the CFLAGS back to vanilla, etc, so while the system is very slightly customized, all flags/etc are standard so code is clean. Here's the results I got. Standard "/usr/bin/time -h make -j5 buildworld" was somewhere around 1h45m (sorry, I didn't write it down the first time), so that's probably the best you'll get. However, after enabling ccache, while the first run was roughly the same (couple minutes longer), the second run (after caching) gave these results: 49m14.74s real 1h28m39.70s user 1h4m8.45s sys So, that sort of breaks the 1 hour limit? I can't imagine there will enough source changes between updates to add 10 minutes to the compile time, but I hear people have had some trouble with ccache and buildworld so whether it solves the problem or not seems sort of up in the air. Hope that helps. I can also give remote access to my box if needed for testing, building updates, etc. if these machines seem to be in short supply. ~Steven dmesg, if you care: real memory = 4294967296 (4096 MB) avail memory = 4183490560 (3989 MB) cpu0: Sun Microsystems UltraSparc-II Processor (450.04 MHz CPU) cpu1: Sun Microsystems UltraSparc-II Processor (450.04 MHz CPU) cpu2: Sun Microsystems UltraSparc-II Processor (450.04 MHz CPU) cpu3: Sun Microsystems UltraSparc-II Processor (450.04 MHz CPU) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs nexus0: pcib0: on nexus0 pcib0: Psycho, impl 0, version 4, ign 0x7c0, bus B pcib0: [FAST] pcib0: [FAST] pcib0: [GIANT-LOCKED] pcib0: [GIANT-LOCKED] pcib0: [FAST] initializing counter-timer Timecounter "counter-timer" frequency 1000000 Hz quality 100 pcib0 dvma: DVMA map: 0xfc000000 to 0xffffffff pci0: on pcib0 ebus0: mem 0x70000000-0x70ffffff,0x71000000-0x717fffff at device 1.0 on pci0 auxio0: addr 0x1400726000-0x1400726003,0x1400728000-0x1400728003,0x140072a000-0x140072a003,0x140072c000-0x140072c003,0x140072f000-0x140072f003 on ebus0 ebus0: addr 0x1400724000-0x1400724003 irq 37 (no driver attached) ebus0: addr 0x1400504000-0x1400504002 (no driver attached) ebus0: addr 0x1400500000-0x1400500007 (no driver attached) puc0: addr 0x1400400000-0x140040007f irq 43 on ebus0 uart0: on puc0 uart0: CTS oflow uart1: on puc0 uart1: CTS oflow uart2: <16550 or compatible> addr 0x14003083f8-0x14003083ff irq 41 on ebus0 uart2: keyboard (1200,n,8,1) kbd0 at sunkbd0 uart3: <16550 or compatible> addr 0x14003062f8-0x14003062ff irq 42 on ebus0 ebus0: addr 0x14003043bc-0x14003043cb,0x1400300398-0x1400300399,0x1400700000-0x140070000f irq 34 (no driver attached) ebus0: addr 0x14003023f0-0x14003023f7,0x1400706000-0x140070600f,0x1400720000-0x1400720003 irq 39 (no driver attached) eeprom0: addr 0x1400000000-0x1400001fff on ebus0 eeprom0: model mk48t59 eeprom0: hostid 80e8d6a7 ebus0: addr 0x1000000000-0x10000fffff (no driver attached) ebus0: addr 0x1400200000-0x14002000ff,0x1400702000-0x140070200f,0x1400704000-0x140070400f,0x1400722000-0x1400722003 irq 35,36 (no driver attached) hme0: mem 0x100000-0x107fff at device 1.1 on pci0 miibus0: on hme0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme0: Ethernet address: 08:00:20:e8:d6:a7 sym0: <875> port 0x1000-0x10ff mem 0x108000-0x1080ff,0x10a000-0x10afff at device 3.0 on pci0 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym0: [GIANT-LOCKED] sym1: <875> port 0x1400-0x14ff mem 0x10c000-0x10c0ff,0x10e000-0x10efff at device 3.1 on pci0 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: [GIANT-LOCKED] pcib1: on nexus0 pcib1: Psycho, impl 0, version 4, ign 0x7c0, bus A pcib1: [FAST] pci1: on pcib1 creator0: on nexus0 creator0: console creator0: resolution 1280x1024 creator1: on nexus0 creator1: resolution 1280x1024 syscons0: on nexus0 syscons0: Unknown <16 virtual consoles, flags=0x300> Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 17274MB (35378533 512 byte sectors: 255H 63S/T 2202C) da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 17274MB (35378533 512 byte sectors: 255H 63S/T 2202C) cd0 at sym0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: cd present [1105880 x 512 byte records] From owner-freebsd-sparc64@FreeBSD.ORG Thu Feb 22 10:53:00 2007 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4373416A402 for ; Thu, 22 Feb 2007 10:53:00 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mx3.netclusive.de (mx3.netclusive.de [89.110.132.133]) by mx1.freebsd.org (Postfix) with ESMTP id CF8AC13C461 for ; Thu, 22 Feb 2007 10:52:59 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (Fdc58.f.ppp-pool.de [195.4.220.88]) by mx3.netclusive.de (Postfix) with ESMTP id 5740D6041BC for ; Thu, 22 Feb 2007 11:52:57 +0100 (CET) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id EEE0C15213; Thu, 22 Feb 2007 11:52:53 +0100 (CET) To: freebsd-sparc64@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.sparc Date: Thu, 22 Feb 2007 11:52:53 +0100 (CET) Organization: Convenimus Projekt Lines: 96 Message-ID: References: <340594530702211358g37430181nf783803ad41f14de@mail.gmail.com> NNTP-Posting-Host: garfield.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1172141573 45365 192.168.100.11 (22 Feb 2007 10:52:53 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Thu, 22 Feb 2007 10:52:53 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD) Subject: Re: good (working) CFLAGS for SPARC64 (Christian Baer) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 10:53:00 -0000 On Wed, 21 Feb 2007 13:58:47 -0800 Steven Hillis wrote: Good morning[1] Steve! > Apologies for the confusion, I gave you working tags from memory, not my > make.conf file (i've been jockeying back and forth between a FreeBSD and a > gentoo box, and use the same tags on them both, -mcpu on gentoo, -mtune on > freebsd). You had me going there for a moment - actually for quite a while. :-) I sat at my computer for hours on end trying to figure out why the heck those flags worked on you machine an not on mine. I don't think you need to apologise for anything though. I read a lot of stuff and bookmarked a lot of new pages that may prove helpful at some time in the future. Mistakes are quite normal for human beings and this one made me do somthing productive for a change. :-) Back to the issue: I'm guessing you know that -mcpu and -mtune do *very* different things. > FreeBSD sparc64 only supports ultrasparc and ultrasparcII cpus, so far as I > know, so -mcpu=ultrasparc is superfluous. I in fact have -mtune=ultrasparc, > since they likely use the v9 standard for FreeBSD since they seem to be > attempting Ultrasparc III support. Again, I'm sorry about my bad memory. > -mcpu=ultrasparc and -m64 should both be useless options under Sparc64, as > far as I can tell. Since I wasn't doing anthing special last night :-) I compiled a new world and stuffed the output info a file instead of stdout. I greped though that and didn't find any -mcpu flags in that. So it is quite likely that the whole thing is being compiled as v7 code - which BTW doesn't mean that it really has to run on an SS20. I'm not sure if this really is the case but it is quite likely that there is no mcpu set. During my research I have found several sites claiming that usually there is not mcpu set - on most operating systems. NetBSD was often used as an example. Ok, unlike FreeBSD that also has a branch for SPARC32, but especially in *that* case you'd think that this flag *should* be set in the SPARC64 branch. All of these sites I found didn't actually go into compiling the OS itself but usually went for some apps running under the OS, usually OpenSSL or OpenSSH. Creating 64bit code (the -m64 flag) should *not* be set globally (IMHO). This really only sets the pointer and long to 64 bits. It could cause problems with some software that rely on a long with 32 bits only (if there is any out there). -m64 isn't faster per definition. Only programs using a lot of pointers (like chess programs) may profit from this setting. AFAIK even under Solaris the default is -m32. Is many cases -m64 is slower than -m32. > My actual make.conf file is as follows: > CFLAGS=-O2 -pipe -mtune=ultrasparc -mvis -mapp-regs -fomit-frame-pointer > -ffast-math -fweb -frename-registers > COPTFLAGS=-O2 -pipe -mtune=ultrasparc -mvis -mapp-regs -fomit-frame-pointer > -ffast-math -fweb -frename-registers I must admit that I'd be a bit to chicken to enable all of those. The ffast-math can cause some "strange" results in some programs and if it does it may take ages to track down where the problem comes from. Have you had any problems with these at all? I believe that buildworld compiles with these settings but have you ever had any problems with other software (compiling and/or running)? > NO_MODULES=YES > NO_PROFILE=YES Why? [2] > .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && > !defined(NOCCACHE) > CC=/usr/local/libexec/ccache/world-cc > CXX=/usr/local/libexec/ccache/world-c++ > .endif I can read this script, but I don't quite see what it does for you. Have you replaced the default cc with something else like a newer gcc? > Those flags compile without a hitch. Again, Sparc64 is only for ultrasparc > CPUs, so that's not really needed. > The question is (this is aimed at Marius, et al), why does setting the -mcpu > flag unset the __sparc64__ definition in so many places? This is what your > errors came from, there are about 20 files that will do that. Setting the mcpu flag at all will actually cause that. So it doesn't matter if I set it so ultrasparc or v9, this effect kicks in all the time. Regards Chris [1] At least here in Germany it is. :-) [2] Trying to learn something here, not meant critically. From owner-freebsd-sparc64@FreeBSD.ORG Thu Feb 22 14:30:13 2007 Return-Path: X-Original-To: sparc64@freebsd.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C1F916A400; Thu, 22 Feb 2007 14:30:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id F26F213C4BE; Thu, 22 Feb 2007 14:30:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l1MEUCZI007730; Thu, 22 Feb 2007 09:30:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l1MEUCOa031975; Thu, 22 Feb 2007 09:30:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id ECF707303D; Thu, 22 Feb 2007 09:30:11 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070222143011.ECF707303D@freebsd-current.sentex.ca> Date: Thu, 22 Feb 2007 09:30:11 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 14:30:13 -0000 TB --- 2007-02-22 13:58:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-02-22 13:58:27 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-02-22 13:58:27 - cleaning the object tree TB --- 2007-02-22 13:59:02 - checking out the source tree TB --- 2007-02-22 13:59:02 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-02-22 13:59:02 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-02-22 14:11:08 - building world (CFLAGS=-O2 -pipe) TB --- 2007-02-22 14:11:08 - cd /src TB --- 2007-02-22 14:11:08 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 22 14:11:10 UTC 2007 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/net/rthdr.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/net/sctp_sys_calls.c /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:319: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:365: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:384: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-02-22 14:30:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-02-22 14:30:11 - ERROR: failed to build world TB --- 2007-02-22 14:30:11 - tinderbox aborted TB --- 0.65 user 2.41 system 1903.80 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Thu Feb 22 14:30:13 2007 Return-Path: X-Original-To: sparc64@freebsd.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FF3B16A406; Thu, 22 Feb 2007 14:30:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id F258F13C4BA; Thu, 22 Feb 2007 14:30:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l1MEUCrT007729; Thu, 22 Feb 2007 09:30:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l1MEUCor031974; Thu, 22 Feb 2007 09:30:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F26257303E; Thu, 22 Feb 2007 09:30:11 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070222143011.F26257303E@freebsd-current.sentex.ca> Date: Thu, 22 Feb 2007 09:30:11 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 14:30:14 -0000 TB --- 2007-02-22 14:04:05 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-02-22 14:04:05 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-02-22 14:04:05 - cleaning the object tree TB --- 2007-02-22 14:04:42 - checking out the source tree TB --- 2007-02-22 14:04:42 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-02-22 14:04:42 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-02-22 14:11:08 - building world (CFLAGS=-O2 -pipe) TB --- 2007-02-22 14:11:08 - cd /src TB --- 2007-02-22 14:11:08 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 22 14:11:10 UTC 2007 >>> 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 [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/net/rthdr.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/lib/libc/net/sctp_sys_calls.c /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getpaddrs': /src/lib/libc/net/sctp_sys_calls.c:303: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:319: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c: In function `sctp_getladdrs': /src/lib/libc/net/sctp_sys_calls.c:365: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/lib/libc/net/sctp_sys_calls.c:384: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-02-22 14:30:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-02-22 14:30:11 - ERROR: failed to build world TB --- 2007-02-22 14:30:11 - tinderbox aborted TB --- 0.64 user 1.99 system 1565.78 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 23 05:38:04 2007 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4020F16A400 for ; Fri, 23 Feb 2007 05:38:04 +0000 (UTC) (envelope-from evultrole@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 6F6A213C441 for ; Fri, 23 Feb 2007 05:38:03 +0000 (UTC) (envelope-from evultrole@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so539360nfc for ; Thu, 22 Feb 2007 21:38:02 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=B+8Wr4d7nlipEd2gLQIfGWscmTW/RZb27x3I+zevXBzBraf5j4NBhc7ribL35Nyag+KkhxCpMy1hvz+8ZuheeZMX8+w11u0QFzWBNdpQKV/aRo0l9mgpJombuFq0pXCXECzLU5UrSCeiTWRxzc2zyaiFeR/j9blesfIRtIAy88I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=SOVng4X6FbuHbMeRwFGiHTHJpKYX5AHO91h1SwMsoemXt85zEfjG/cfv4GhJvrDN7HrF6B1XGr2rQs9aMRLAYkwM8O82ORbR7UYKK9fH9Dak+yo1Pm+04DT/hbJLzWagCjIkGYCE8xAh8yfEytOHON55Ck9Cs9L3iVx9dNc1bas= Received: by 10.78.189.5 with SMTP id m5mr128439huf.1172209082091; Thu, 22 Feb 2007 21:38:02 -0800 (PST) Received: by 10.78.178.6 with HTTP; Thu, 22 Feb 2007 21:38:02 -0800 (PST) Message-ID: <340594530702222138t5c42001brb3759fd46b85eb3e@mail.gmail.com> Date: Thu, 22 Feb 2007 21:38:02 -0800 From: "Steven Hillis" To: freebsd-sparc64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: good (working) CFLAGS for SPARC64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 05:38:04 -0000 >> Apologies for the confusion, I gave you working tags from memory, not my >> make.conf file (i've been jockeying back and forth between a FreeBSD and a >> gentoo box, and use the same tags on them both, -mcpu on gentoo, -mtune on >> freebsd). >You had me going there for a moment - actually for quite a while. :-) I >sat at my computer for hours on end trying to figure out why the heck >those flags worked on you machine an not on mine. I don't think you need >to apologise for anything though. I read a lot of stuff and bookmarked a >lot of new pages that may prove helpful at some time in the future. >Mistakes are quite normal for human beings and this one made me do >somthing productive for a change. :-) I actually redid the computer before double checking my old make.conf for the timed make world test and put that flag in as well, spent several minutes actually fixing the problems that came up, then remembered what was happening... >.< >I'm guessing you know that -mcpu and -mtune do *very* different things. Indeed, mcpu sets registers and many other things, mtune simply sets possible register allocation within a broader set without breaking compatibility, however mcpu=ultrasparc seems to be a combination of mcpu=v9 & mtune=ultrasparc, so in many cases the things done are only vastly different in one direction. >> FreeBSD sparc64 only supports ultrasparc and ultrasparcII cpus, so far as I >> know, so -mcpu=ultrasparc is superfluous. I in fact have -mtune=ultrasparc, >> since they likely use the v9 standard for FreeBSD since they seem to be >> attempting Ultrasparc III support. Again, I'm sorry about my bad memory. >> -mcpu=ultrasparc and -m64 should both be useless options under Sparc64, as >> far as I can tell. >Since I wasn't doing anthing special last night :-) I compiled a new >world and stuffed the output info a file instead of stdout. I greped >though that and didn't find any -mcpu flags in that. So it is quite >likely that the whole thing is being compiled as v7 code - which BTW >doesn't mean that it really has to run on an SS20. I'm not sure if this >really is the case but it is quite likely that there is no mcpu set. >During my research I have found several sites claiming that usually >there is not mcpu set - on most operating systems. NetBSD was often used >as an example. Ok, unlike FreeBSD that also has a branch for SPARC32, >but especially in *that* case you'd think that this flag *should* be set >in the SPARC64 branch. Everything I've ever seen on NetBSD suggests that it defaults to installing the Sparc64 branch with mcpu=v9 flags, so it would follow that Sparc64 on FreeBSD does as well... however, lack of flags anywhere would call that into question. Lack of flags does not imply it is not the case, however, as the default settings of GCC would not show up in any compile lines, being default and all (I don't think -m64 shows up in any lines either). This, and lack of support for anything in the v8 line or lower, draws my conclusion that v9 is already set by default. I will see if I can track down an exact setting over the next 20 minutes (not 100% sure where to look for that, so it will take me awhile) Incidentally, I believe manually setting the -mcpu=v9 flag gave me the same "unknown architecture" crap, but I think it's just using a non-default mcpu flag that is causing the issue somehow. >Creating 64bit code (the -m64 flag) should *not* be set globally (IMHO). >This really only sets the pointer and long to 64 bits. It could cause >problems with some software that rely on a long with 32 bits only (if >there is any out there). -m64 isn't faster per definition. Only programs >using a lot of pointers (like chess programs) may profit from this >setting. AFAIK even under Solaris the default is -m32. Is many cases -m64 >is slower than -m32. NetBSD also has -m64 as the default flag, as far as I can tell. Yes, I am aware of the problems inherent in this (firefox, cough cough), but (again from NetBSD, circa 1.6) the userland in many 64 bit systems can't properly build anything with the -m32 flag even set. >> My actual make.conf file is as follows: >> CFLAGS=-O2 -pipe -mtune=ultrasparc -mvis -mapp-regs -fomit-frame-pointer >> -ffast-math -fweb -frename-registers >> COPTFLAGS=-O2 -pipe -mtune=ultrasparc -mvis -mapp-regs -fomit-frame-pointer >> -ffast-math -fweb -frename-registers >I must admit that I'd be a bit to chicken to enable all of those. The >ffast-math can cause some "strange" results in some programs and if it >does it may take ages to track down where the problem comes from. >Have you had any problems with these at all? I believe that buildworld >compiles with these settings but have you ever had any problems with >other software (compiling and/or running)? As I said before, I know many people would scold the use of such things. I have had no issues with any program compiles, nor any strange stability issues, but I don't use any really math heavy science programs so my lack of problems does not imply that it is a safe thing to use. >> NO_MODULES=YES >> NO_PROFILE=YES >Why? [2] Why no profile? With profiling enabled many programs build with the -pg flag, which is not compatible with -fomit-frame-pointers (build error) so I just disable them ahead of time to save the hastle. I don't make a point of debugging in my spare time, so I don't really care about it greatly. The no modules I just use because I'm lazy and see no point in the kernel compiling drivers for a scsi card I don't use, own, or even know how/where to find. It's also not necessarily a good flag for common use, it just works well for my purposes. >> .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && >> !defined(NOCCACHE) >> CC=/usr/local/libexec/ccache/world-cc >> CXX=/usr/local/libexec/ccache/world-c++ >> .endif >I can read this script, but I don't quite see what it does for you. Have >you replaced the default cc with something else like a newer gcc? I just installed ccache to test how it would affect buildworld speed (someone was asking about time on an ultra 80, so I used ccache to bring it down under 1 hour) >> Those flags compile without a hitch. Again, Sparc64 is only for ultrasparc >> CPUs, so that's not really needed. >> The question is (this is aimed at Marius, et al), why does setting the -mcpu >> flag unset the __sparc64__ definition in so many places? This is what your >> errors came from, there are about 20 files that will do that. >Setting the mcpu flag at all will actually cause that. So it doesn't >matter if I set it so ultrasparc or v9, this effect kicks in all the >time. Anyway, I think (I'm far from a proficient programmer mind you) that the problem goes back to the /usr/src/contrib/gcc/config/sparc.h file, which sets CPP_SPEC to __sparc_v9__ with any mcpu flags, while freebsd works with __sparc64__, but that's after only about 10 seconds of looking at a search for mcpu=v9 in the full source tree, and only doing a key word search in that particular file... I haven't bothered to look back at any other source files to confirm that yet... anyway, I'll see what I can find about it tonight and I'll let you know if that is in fact it. From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 23 19:55:13 2007 Return-Path: X-Original-To: sparc64@freebsd.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE83916A405; Fri, 23 Feb 2007 19:55:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7149C13C47E; Fri, 23 Feb 2007 19:55:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l1NJtCnF079624; Fri, 23 Feb 2007 14:55:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id l1NJtC2g014611; Fri, 23 Feb 2007 14:55:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 997DD73039; Fri, 23 Feb 2007 14:55:11 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070223195512.997DD73039@freebsd-current.sentex.ca> Date: Fri, 23 Feb 2007 14:55:09 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 19:55:13 -0000 TB --- 2007-02-23 17:34:51 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-02-23 17:34:51 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-02-23 17:34:51 - cleaning the object tree TB --- 2007-02-23 17:36:28 - checking out the source tree TB --- 2007-02-23 17:36:28 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-02-23 17:36:28 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-02-23 18:03:30 - building world (CFLAGS=-O2 -pipe) TB --- 2007-02-23 18:03:30 - cd /src TB --- 2007-02-23 18:03:30 - /usr/bin/make -B buildworld >>> World build started on Fri Feb 23 18:03:31 UTC 2007 >>> 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 >>> World build completed on Fri Feb 23 19:48:16 UTC 2007 TB --- 2007-02-23 19:48:16 - generating LINT kernel config TB --- 2007-02-23 19:48:16 - cd /src/sys/sparc64/conf TB --- 2007-02-23 19:48:16 - /usr/bin/make -B LINT TB --- 2007-02-23 19:48:16 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-02-23 19:48:16 - cd /src TB --- 2007-02-23 19:48:16 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 23 19:48:16 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/cardbus/cardbus_device.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ciss/ciss.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/cm/smc90cx6.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/cnw/if_cnw.c /src/sys/dev/cnw/if_cnw.c: In function `cnw_pccard_attach': /src/sys/dev/cnw/if_cnw.c:1635: warning: passing arg 4 of `bus_setup_intr' from incompatible pointer type /src/sys/dev/cnw/if_cnw.c:1635: warning: passing arg 5 of `bus_setup_intr' from incompatible pointer type /src/sys/dev/cnw/if_cnw.c:1635: error: too few arguments to function `bus_setup_intr' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-02-23 19:55:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-02-23 19:55:08 - ERROR: failed to build lint kernel TB --- 2007-02-23 19:55:08 - tinderbox aborted TB --- 0.73 user 2.43 system 8417.12 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 23 20:47:37 2007 Return-Path: X-Original-To: sparc64@freebsd.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0451E16A406; Fri, 23 Feb 2007 20:47:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id BA70B13C4B6; Fri, 23 Feb 2007 20:47:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l1NKlaiq087853; Fri, 23 Feb 2007 15:47:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l1NKlaCv092564; Fri, 23 Feb 2007 15:47:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 04F2873039; Fri, 23 Feb 2007 15:47:34 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070223204736.04F2873039@freebsd-current.sentex.ca> Date: Fri, 23 Feb 2007 15:47:34 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 20:47:37 -0000 TB --- 2007-02-23 19:04:18 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-02-23 19:04:18 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-02-23 19:04:18 - cleaning the object tree TB --- 2007-02-23 19:05:29 - checking out the source tree TB --- 2007-02-23 19:05:29 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-02-23 19:05:29 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-02-23 19:29:21 - building world (CFLAGS=-O2 -pipe) TB --- 2007-02-23 19:29:21 - cd /src TB --- 2007-02-23 19:29:21 - /usr/bin/make -B buildworld >>> World build started on Fri Feb 23 19:29:23 UTC 2007 >>> 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 >>> World build completed on Fri Feb 23 20:39:47 UTC 2007 TB --- 2007-02-23 20:39:47 - generating LINT kernel config TB --- 2007-02-23 20:39:47 - cd /src/sys/sun4v/conf TB --- 2007-02-23 20:39:47 - /usr/bin/make -B LINT TB --- 2007-02-23 20:39:48 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-02-23 20:39:48 - cd /src TB --- 2007-02-23 20:39:48 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 23 20:39:48 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/cardbus/cardbus_device.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/ciss/ciss.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/cm/smc90cx6.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/cnw/if_cnw.c /src/sys/dev/cnw/if_cnw.c: In function `cnw_pccard_attach': /src/sys/dev/cnw/if_cnw.c:1635: warning: passing arg 4 of `bus_setup_intr' from incompatible pointer type /src/sys/dev/cnw/if_cnw.c:1635: warning: passing arg 5 of `bus_setup_intr' from incompatible pointer type /src/sys/dev/cnw/if_cnw.c:1635: error: too few arguments to function `bus_setup_intr' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-02-23 20:47:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-02-23 20:47:33 - ERROR: failed to build lint kernel TB --- 2007-02-23 20:47:33 - tinderbox aborted TB --- 0.59 user 1.96 system 6195.05 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-sparc64@FreeBSD.ORG Fri Feb 23 22:10:01 2007 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DEEC16A405 for ; Fri, 23 Feb 2007 22:10:01 +0000 (UTC) (envelope-from evultrole@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id E263313C442 for ; Fri, 23 Feb 2007 22:10:00 +0000 (UTC) (envelope-from evultrole@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so771921nfc for ; Fri, 23 Feb 2007 14:09:56 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=JAsnOQiHGZ0QvRm9NwcC4869enZbZizfoX7iL0zpxpDV1EtfZ9izRYTR9R1hG/SeIhUVnbb3abhwhd1FsEGBuQ3OOH32zjQ4Ir0nKDoDr9pJgBT5eokALpFzJCo4dev5qucRPBASTp2I5xH4P6kDS93OlTZk7a18VlG07+0rBJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=g6wjDKvVKMLu4Qbqzb/gEPqPkiLjlDdD3uqXBX0Pce6fpEFUAkNEY2bCH8Qb2bEcDuv+wL8LUKHACTnz0i39cGWfR0d27cAM3maDR/75gFb8KXPBoZ+h4Jt20YU3hj1YsWvbk7Lzx/FqPgd8sy/CNQz/tiyY8oezwUb4Y9Vedck= Received: by 10.78.204.7 with SMTP id b7mr231379hug.1172268596155; Fri, 23 Feb 2007 14:09:56 -0800 (PST) Received: by 10.78.178.6 with HTTP; Fri, 23 Feb 2007 14:09:51 -0800 (PST) Message-ID: <340594530702231409i15b257dwdb39d52a62ab9a0a@mail.gmail.com> Date: Fri, 23 Feb 2007 14:09:51 -0800 From: "Steven Hillis" To: freebsd-sparc64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: good (working) CFLAGS for SPARC64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 22:10:01 -0000 So, changing the __sparc_v9__ to __sparc64___ in 5 files (something for asm in bind9 and four files in contrib/gcc/config/sparc, only two of which are actually used) makes CPU flags work properly. I do not yet know whether it disables their effects or not (i.e. does setting it to __sparc_v9__ have some effect on the code output, or is it an arbitrary label with optimizations controlled by the -Av9a thing?) I have compiled the tree successfully using mcpu=ultrasparc after very few changes, and am trying to work up a proper benchmark to see if it actually did anything at all. The other side (if this just disabled their effects) consists of replacing all the ifdef __sparc64__ lines with if defined(__sparc64__) || defined(__sparc_v9__) in about 400 places, none of which are just standard lines I can swap out using sed... so I'm hoping I can fix it with the 5 changes rather than the other way around... I'll up a source diff after I get it worked out properly. Incidentally, bzip2 works at exactly the same speed with the mcpu flag set for compile and with a standard compile... that means one of three things: code is already set to ultrasparc || I disabled the mcpu flag effects || ultrasparc has too many cache hits for optimization to matter in compression programs. I don't really know enough about the internals of the GCC optimization settings and how flags affect it to be certain until I get some sort of real number on this (currently I'm trying to just use average build time for buildworld and comparing mcpu'd gcc with non) so if anyone can shed light on what that does (just a quick sentence or two) that would probably help. From owner-freebsd-sparc64@FreeBSD.ORG Sat Feb 24 17:39:20 2007 Return-Path: X-Original-To: sparc64@freebsd.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1C2D16A402; Sat, 24 Feb 2007 17:39:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 742E913C428; Sat, 24 Feb 2007 17:39:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l1OHdJx4080917; Sat, 24 Feb 2007 12:39:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l1OHdJb2032323; Sat, 24 Feb 2007 12:39:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 82BC073039; Sat, 24 Feb 2007 12:39:18 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070224173919.82BC073039@freebsd-current.sentex.ca> Date: Sat, 24 Feb 2007 12:39:18 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2007 17:39:20 -0000 TB --- 2007-02-24 15:49:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-02-24 15:49:33 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-02-24 15:49:33 - cleaning the object tree TB --- 2007-02-24 15:51:08 - checking out the source tree TB --- 2007-02-24 15:51:08 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-02-24 15:51:08 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-02-24 16:06:47 - building world (CFLAGS=-O2 -pipe) TB --- 2007-02-24 16:06:47 - cd /src TB --- 2007-02-24 16:06:47 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 24 16:06:48 UTC 2007 >>> 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 >>> World build completed on Sat Feb 24 17:23:31 UTC 2007 TB --- 2007-02-24 17:23:31 - generating LINT kernel config TB --- 2007-02-24 17:23:31 - cd /src/sys/sparc64/conf TB --- 2007-02-24 17:23:31 - /usr/bin/make -B LINT TB --- 2007-02-24 17:23:31 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-02-24 17:23:31 - cd /src TB --- 2007-02-24 17:23:31 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 24 17:23:31 UTC 2007 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror vers.c linking kernel raw_ip6.o(.bss+0x20): multiple definition of `ip6_mrouter' ip6_mroute.o(.bss+0x8): first defined here *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-02-24 17:39:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-02-24 17:39:18 - ERROR: failed to build lint kernel TB --- 2007-02-24 17:39:18 - tinderbox aborted TB --- 0.66 user 2.45 system 6584.96 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Sat Feb 24 17:56:17 2007 Return-Path: X-Original-To: sparc64@freebsd.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E48D916A402; Sat, 24 Feb 2007 17:56:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id A77BB13C46B; Sat, 24 Feb 2007 17:56:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l1OHuHN2082065; Sat, 24 Feb 2007 12:56:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id l1OHuG3H080365; Sat, 24 Feb 2007 12:56:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5941A73039; Sat, 24 Feb 2007 12:56:15 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070224175615.5941A73039@freebsd-current.sentex.ca> Date: Sat, 24 Feb 2007 12:56:14 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2007 17:56:18 -0000 TB --- 2007-02-24 16:11:53 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-02-24 16:11:53 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-02-24 16:11:53 - cleaning the object tree TB --- 2007-02-24 16:12:39 - checking out the source tree TB --- 2007-02-24 16:12:39 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-02-24 16:12:39 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-02-24 16:28:04 - building world (CFLAGS=-O2 -pipe) TB --- 2007-02-24 16:28:04 - cd /src TB --- 2007-02-24 16:28:04 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 24 16:28:05 UTC 2007 >>> 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 >>> World build completed on Sat Feb 24 17:43:50 UTC 2007 TB --- 2007-02-24 17:43:51 - generating LINT kernel config TB --- 2007-02-24 17:43:51 - cd /src/sys/sun4v/conf TB --- 2007-02-24 17:43:51 - /usr/bin/make -B LINT TB --- 2007-02-24 17:43:51 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-02-24 17:43:51 - cd /src TB --- 2007-02-24 17:43:51 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 24 17:43:51 UTC 2007 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror vers.c linking kernel raw_ip6.o(.bss+0x20): multiple definition of `ip6_mrouter' ip6_mroute.o(.bss+0x8): first defined here *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-02-24 17:56:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-02-24 17:56:14 - ERROR: failed to build lint kernel TB --- 2007-02-24 17:56:14 - tinderbox aborted TB --- 0.57 user 2.01 system 6261.52 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full