From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 00:39:55 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FDC316A420 for ; Sun, 4 Nov 2007 00:39:55 +0000 (UTC) (envelope-from craig001@lerwick.hopto.org) Received: from lerwick.hopto.org (81-86-235-79.dsl.pipex.com [81.86.235.79]) by mx1.freebsd.org (Postfix) with SMTP id 711AF13C494 for ; Sun, 4 Nov 2007 00:39:54 +0000 (UTC) (envelope-from craig001@lerwick.hopto.org) Received: (qmail 50216 invoked by uid 98); 4 Nov 2007 00:36:40 +0000 Received: from 192.168.0.5 by polaris.lerwick.hopto.org (envelope-from , uid 82) with qmail-scanner-2.01 (clamdscan: 0.88.4/1789. hbedv: 7.1.1.11/6.35.1.178. f-prot: 4.6.6/3.16.14. spamassassin: 3.1.4. Clear:RC:1(192.168.0.5):. Processed in 4.316913 secs); 04 Nov 2007 00:36:40 -0000 Received: from trident.lerwick.hopto.org (192.168.0.5) by lerwick.hopto.org with SMTP; 4 Nov 2007 00:36:36 +0000 Message-ID: <472D149A.2040400@lerwick.hopto.org> Date: Sun, 04 Nov 2007 00:38:50 +0000 From: Craig Butler User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Kris Kennaway References: <200711011822.25884.linimon@lonesome.com> <472B39A8.3070708@alaska.net> <472CD183.8080905@FreeBSD.org> In-Reply-To: <472CD183.8080905@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Linimon , Christian Baer , freebsd-sparc64@freebsd.org Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 00:39:55 -0000 Kris Kennaway wrote: > Royce Williams wrote: >> Mark Linimon wrote, on 11/1/2007 3:22 PM: >>> The latest sparc64-7 run is continuing. With the limited number of >>> sparc64 machines we have, the elapsed time for even _incremental_ >>> builds is on the order of 3-5 weeks, depending on what's changed in >>> the meantime. Once that gets done, I'll probably do another pass. >> >> I've started a couple of threads in the past about offering to chip in >> for hardware to support builds, and especially sparc64 freebsd-update. >> >> To move forward on that, what is the 'best bang for the buck' hardware >> that the project could use? > > To be minimally useful for package builds the machines would need at > least 512MB RAM (preferably more, at least 1GB), and CPU speed is > obviously highly important (but also hard to come by with sparc64 > hardware). > > Kris > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to > "freebsd-sparc64-unsubscribe@freebsd.org" What about us running the builds for you ? Our company is about to invest in some dated b1600 full of sparc blades. I am sure I can borrow some cpu time from them ;) ============================================================ This email has been handled by lerwick.hopto.org mail server and has been scanned by 3 virus killers and spamassassin ============================================================ From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 00:51:46 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7C8F16A420 for ; Sun, 4 Nov 2007 00:51:46 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 6C90F13C4A5; Sun, 4 Nov 2007 00:51:45 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <472D17A0.2030504@FreeBSD.org> Date: Sun, 04 Nov 2007 01:51:44 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Craig Butler References: <200711011822.25884.linimon@lonesome.com> <472B39A8.3070708@alaska.net> <472CD183.8080905@FreeBSD.org> <472D149A.2040400@lerwick.hopto.org> In-Reply-To: <472D149A.2040400@lerwick.hopto.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Linimon , Christian Baer , freebsd-sparc64@freebsd.org Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 00:51:46 -0000 Craig Butler wrote: > Kris Kennaway wrote: >> Royce Williams wrote: >>> Mark Linimon wrote, on 11/1/2007 3:22 PM: >>>> The latest sparc64-7 run is continuing. With the limited number of >>>> sparc64 machines we have, the elapsed time for even _incremental_ >>>> builds is on the order of 3-5 weeks, depending on what's changed in >>>> the meantime. Once that gets done, I'll probably do another pass. >>> >>> I've started a couple of threads in the past about offering to chip in >>> for hardware to support builds, and especially sparc64 freebsd-update. >>> >>> To move forward on that, what is the 'best bang for the buck' hardware >>> that the project could use? >> >> To be minimally useful for package builds the machines would need at >> least 512MB RAM (preferably more, at least 1GB), and CPU speed is >> obviously highly important (but also hard to come by with sparc64 >> hardware). >> >> Kris >> _______________________________________________ >> freebsd-sparc64@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 >> To unsubscribe, send any mail to >> "freebsd-sparc64-unsubscribe@freebsd.org" > > > What about us running the builds for you ? Our company is about to > invest in some dated b1600 full of sparc blades. I am sure I can borrow > some cpu time from them ;) We would need remote access, the builds are managed from a centralized server. If that is possible then this might be useful. Kris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 11:03:51 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B1B216A41B for ; Sun, 4 Nov 2007 11:03:51 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mx4.netclusive.de (mx4.netclusive.de [89.110.132.136]) by mx1.freebsd.org (Postfix) with ESMTP id E50F113C48E for ; Sun, 4 Nov 2007 11:03:50 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (sub87-230-112-188.he-dsl.de [87.230.112.188]) (Authenticated sender: ncf1534p2) by mx4.netclusive.de (Postfix) with ESMTP id DA6655E0189 for ; Sun, 4 Nov 2007 12:03:37 +0100 (CET) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id D6EC915217; Sun, 4 Nov 2007 11:49:39 +0100 (CET) To: freebsd-sparc64@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.sparc Date: Sun, 4 Nov 2007 11:49:39 +0100 (CET) Organization: Convenimus Projekt Lines: 32 Message-ID: References: NNTP-Posting-Host: sunny.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1194173379 41134 192.168.100.5 (4 Nov 2007 10:49:39 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Sun, 4 Nov 2007 10:49:39 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD/6.2-RELEASE-p8 (sparc64)) Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 11:03:51 -0000 On Mon, 22 Oct 2007 01:17:37 -0400 Miles Nordin wrote: >> Why hasn't anyone done that with these (and possibly other) >> ports yet? Thunderbird and Firefox have been broken for ages > sometimes there are reports of them working (a little). but, yeah, it > is reasonable to want to know, even before buying hardware much less > compiling, whether this port has a working browser or not. The issue isn't so much a working browser in itself. If I really wanted that, I could use Solaris, where Firefox and Thunderbird (and probably most other apps too) have a 32bit ABI. I didn't buy this hardware to work with FreeBSD either, I got it for free (a friend of mine wasn't using it anymore). The point was more or less that every user has to find out for him or herself, that these ports won't work. And if you compile these two with a Sun, you invest quite some time. > Isn't there some spot in the FreeBSD base system where you have to > choose your thread library, and one works better on sparc64 than the > other? Is the thread library that works best on sparc64 set as the > default right now? There was a change in the kernel threading in NetBSD a short while ago and since then Firefox seems to work. This change isn't possible in FreeBSD though. Besides, I'm not even sure that was the real cause of the problem. I also read on one of the NetBSD mailing lists that Firefox was now a 32bit app in pgksrc. So now it runs in the same mode as under Solaris (basicly). Regards Chris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 11:17:54 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3088616A417 for ; Sun, 4 Nov 2007 11:17:54 +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 C0EA613C4A8 for ; Sun, 4 Nov 2007 11:17:53 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (sub87-230-112-188.he-dsl.de [87.230.112.188]) (Authenticated sender: ncf1534p2) by mx2.netclusive.de (Postfix) with ESMTP id 7AA7926030F for ; Sun, 4 Nov 2007 12:17:41 +0100 (CET) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id 757F015217; Sun, 4 Nov 2007 12:03:44 +0100 (CET) To: freebsd-sparc64@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.sparc Date: Sun, 4 Nov 2007 12:03:44 +0100 (CET) Organization: Convenimus Projekt Lines: 54 Message-ID: References: <200711011822.25884.linimon@lonesome.com> NNTP-Posting-Host: sunny.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1194174224 41134 192.168.100.5 (4 Nov 2007 11:03:44 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Sun, 4 Nov 2007 11:03:44 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD/6.2-RELEASE-p8 (sparc64)) Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 11:17:54 -0000 On Thu, 1 Nov 2007 18:22:25 -0500 Mark Linimon wrote: > Sorry to come in on this discussion late. I am behind on email. Ain't we all? :-) > I'm one of the people who goes through the ports and marks them > broken -- at least on the basis of the build cluster runs. As of > the last complete run on sparc64-6, I think I did indeed mark those. Were are these marks? I don't really expect them to jump right in my face when I try to compile a port (like Seti@home did) but I'm not sure I want to have to did for ages to find the marks either. > The latest sparc64-7 run is continuing. With the limited number of > sparc64 machines we have, the elapsed time for even _incremental_ > builds is on the order of 3-5 weeks, depending on what's changed in > the meantime. Once that gets done, I'll probably do another pass. That may change a little once the much faster III CPUs (or rather: the chipsets beneath them) are supported. We won't be anywhere near the CPU power that i386 has (the Pentium IV and AthlonXP did go pretty far there) but at least we will be at up to 1GHz. > As for ports that compile and install correctly, but just don't work, > we rely on our user base to file PRs. But there is a bit of chicken- > and-egg problem: not many maintainers have access to these machines. > Much more so than on i386, we are reliant on user fixes. Keepassx probably isn't used all that much by itself and it quite possible that only a handfull of people tried it under FreeBSD/sparc64. So I am not really shocked that noone noticed that (yet). However, the same certainly will not apply for Firefox and Thunderbird which are quite common apps on Unix plattforms. So there should have been some input there. > I personally think it's still worth putting work into sparc ports, > if for nothing else the potential for a solid, working, FreeBSD/sun4v ^^^^^ Someone is working on FreeBSD/sparc32? > down the road. But with the resources we have right now, the priorities > are: i386, amd64, then sparc64. I realise this. FreeBSD started out on i386, even Alpha came a fair bit later (btw. where is that along the list). I also realise that FreeBSD and sparc64 is still a quite exotic combination and will probably remain that way for some time to come. So sparc64 won't be the most important plattform to FreeBSD. There are no complaints about this. I'm just wondering how two really common apps that have been broken for quite a while now could just slip through the grid. Regards, Chris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 11:28:25 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40B2F16A41B for ; Sun, 4 Nov 2007 11:28:25 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 950E613C48D; Sun, 4 Nov 2007 11:28:24 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <472DACD7.6040501@FreeBSD.org> Date: Sun, 04 Nov 2007 12:28:23 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christian Baer References: <200711011822.25884.linimon@lonesome.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@freebsd.org Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 11:28:25 -0000 Christian Baer wrote: ^^^^^ > Someone is working on FreeBSD/sparc32? FreeBSD does not support 32-bit sparc and it is unlikely it ever will. > I'm just wondering how two really common apps that have been broken for > quite a while now could just slip through the grid. Few people use sparc64 on their desktop. That means that if you want to do that you are running without the benefit of a large testing community, and you will have to shoulder part of that burden yourself. Kris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 11:36:12 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC65716A41B for ; Sun, 4 Nov 2007 11:36:12 +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 91C1113C4AC for ; Sun, 4 Nov 2007 11:36:12 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (sub87-230-112-188.he-dsl.de [87.230.112.188]) (Authenticated sender: ncf1534p2) by mx2.netclusive.de (Postfix) with ESMTP id 532962603F7 for ; Sun, 4 Nov 2007 12:35:50 +0100 (CET) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id DE8991521D; Sun, 4 Nov 2007 12:21:52 +0100 (CET) To: freebsd-sparc64@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.sparc Date: Sun, 4 Nov 2007 12:21:52 +0100 (CET) Organization: Convenimus Projekt Lines: 20 Message-ID: References: <200711011822.25884.linimon@lonesome.com> <472B39A8.3070708@alaska.net> NNTP-Posting-Host: sunny.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1194175312 41134 192.168.100.5 (4 Nov 2007 11:21:52 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Sun, 4 Nov 2007 11:21:52 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD/6.2-RELEASE-p8 (sparc64)) Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 11:36:12 -0000 On Fri, 02 Nov 2007 06:52:24 -0800 Royce Williams wrote: > I've started a couple of threads in the past about offering to chip in > for hardware to support builds, and especially sparc64 freebsd-update. > To move forward on that, what is the 'best bang for the buck' hardware > that the project could use? The fastest CPU that are currently supported by FreeBSD are 650MHz IIi. You can find that in a Blade 150. There are no workstations with more than one CPU of this type around (that I know of). The U80 has up to four 450MHz CPUs. So this is (probably) the fastest sparc64-workstation currently supported by FreeBSD. Since the ports cannot be compiled with more than one job at a time (make -j 2 breaks most of the builds), I'm not sure if more than one CPU would be of much use - for building the ports. However, if only one job is run, the workstation would still be usable for other things while compiling. Regards, Chris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 11:38:44 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F07616A417 for ; Sun, 4 Nov 2007 11:38:44 +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 E906513C48A for ; Sun, 4 Nov 2007 11:38:43 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (sub87-230-112-188.he-dsl.de [87.230.112.188]) (Authenticated sender: ncf1534p2) by mx3.netclusive.de (Postfix) with ESMTP id D8C31604D15 for ; Sun, 4 Nov 2007 12:04:42 +0100 (CET) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id 7EFEE15217; Sun, 4 Nov 2007 11:50:46 +0100 (CET) To: freebsd-sparc64@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.sparc Date: Sun, 4 Nov 2007 11:50:46 +0100 (CET) Organization: Convenimus Projekt Lines: 10 Message-ID: References: <471CF9AC.6090704@FreeBSD.org> NNTP-Posting-Host: sunny.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1194173446 41134 192.168.100.5 (4 Nov 2007 10:50:46 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Sun, 4 Nov 2007 10:50:46 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD/6.2-RELEASE-p8 (sparc64)) Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 11:38:44 -0000 On Mon, 22 Oct 2007 21:27:40 +0200 Kris Kennaway wrote: > There is only one choice on sparc64. It is likely to be something > within firefox (and related common code) since this is notoriously > fragile on !x86. No, it is fragile on 64bit systems. Regards Chris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 11:40:48 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62F0B16A468 for ; Sun, 4 Nov 2007 11:40:48 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id B2EEA13C48E; Sun, 4 Nov 2007 11:40:47 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <472DAFBE.9070603@FreeBSD.org> Date: Sun, 04 Nov 2007 12:40:46 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christian Baer References: <200711011822.25884.linimon@lonesome.com> <472B39A8.3070708@alaska.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@freebsd.org Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 11:40:48 -0000 Christian Baer wrote: > On Fri, 02 Nov 2007 06:52:24 -0800 Royce Williams wrote: > >> I've started a couple of threads in the past about offering to chip in >> for hardware to support builds, and especially sparc64 freebsd-update. >> To move forward on that, what is the 'best bang for the buck' hardware >> that the project could use? > > The fastest CPU that are currently supported by FreeBSD are 650MHz IIi. > You can find that in a Blade 150. There are no workstations with more than > one CPU of this type around (that I know of). > > The U80 has up to four 450MHz CPUs. So this is (probably) the fastest > sparc64-workstation currently supported by FreeBSD. Since the ports cannot > be compiled with more than one job at a time (make -j 2 breaks most of the > builds), I'm not sure if more than one CPU would be of much use - for > building the ports. However, if only one job is run, the workstation would > still be usable for other things while compiling. That is no problem, even on single CPU machines I run concurrent builds since it turns out to be more efficient. In the past we have even used 14 CPU e4500 machines for package builds although they all died from hardware failure. Kris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 11:41:51 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4F8516A421 for ; Sun, 4 Nov 2007 11:41:51 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 23F1A13C49D; Sun, 4 Nov 2007 11:41:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <472DAFFE.1090900@FreeBSD.org> Date: Sun, 04 Nov 2007 12:41:50 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christian Baer References: <471CF9AC.6090704@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@freebsd.org Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 11:41:51 -0000 Christian Baer wrote: > On Mon, 22 Oct 2007 21:27:40 +0200 Kris Kennaway wrote: > >> There is only one choice on sparc64. It is likely to be something >> within firefox (and related common code) since this is notoriously >> fragile on !x86. > > No, it is fragile on 64bit systems. For the present discussion that is a distinction without a difference. Kris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 11:48:43 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C30F16A474 for ; Sun, 4 Nov 2007 11:48:43 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id E363B13C4B7 for ; Sun, 4 Nov 2007 11:48:42 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 89D078C0BD; Sun, 4 Nov 2007 05:48:11 -0600 (CST) Date: Sun, 4 Nov 2007 05:48:11 -0600 To: Christian Baer Message-ID: <20071104114811.GA19506@soaustin.net> References: <200711011822.25884.linimon@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) Cc: freebsd-sparc64@freebsd.org Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 11:48:43 -0000 On Sun, Nov 04, 2007 at 12:03:44PM +0100, Christian Baer wrote: > Where are these marks? I don't really expect them to jump right in my face > when I try to compile a port BROKEN=string. They'll prevent you from building the port, by default. (You can override it). > So there should have been some input there. Again, it all depends on feedback from our users. > > I personally think it's still worth putting work into sparc ports, > > if for nothing else the potential for a solid, working, FreeBSD/sun4v > ^^^^^ > Someone is working on FreeBSD/sparc32? No, sun4v is the T1000/T2000 series. > I'm just wondering how two really common apps that have been broken for > quite a while now could just slip through the grid. It's just that there is small community of people using sparc64, and an even smaller community of people user sparc64 as a desktop. FreeBSD is the sum of what its volunteers make of it. mcl From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 12:39:06 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4BC816A41B for ; Sun, 4 Nov 2007 12:39:06 +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 77A9E13C4CC for ; Sun, 4 Nov 2007 12:39:06 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (sub87-230-112-188.he-dsl.de [87.230.112.188]) (Authenticated sender: ncf1534p2) by mx1.netclusive.de (Postfix) with ESMTP id 34981DE8109 for ; Sun, 4 Nov 2007 12:42:53 +0100 (CET) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id A450815217; Sun, 4 Nov 2007 12:28:57 +0100 (CET) To: freebsd-sparc64@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.sparc Date: Sun, 4 Nov 2007 12:28:57 +0100 (CET) Organization: Convenimus Projekt Lines: 29 Message-ID: References: <200711011822.25884.linimon@lonesome.com> <472DACD7.6040501@FreeBSD.org> NNTP-Posting-Host: sunny.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1194175737 41134 192.168.100.5 (4 Nov 2007 11:28:57 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Sun, 4 Nov 2007 11:28:57 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD/6.2-RELEASE-p8 (sparc64)) Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 12:39:06 -0000 On Sun, 04 Nov 2007 12:28:23 +0100 Kris Kennaway wrote: > ^^^^^ >> Someone is working on FreeBSD/sparc32? > FreeBSD does not support 32-bit sparc and it is unlikely it ever will. That's why I was a little shocked about the Sun4v. Was that a typo? >> I'm just wondering how two really common apps that have been broken for >> quite a while now could just slip through the grid. > Few people use sparc64 on their desktop. That means that if you want to > do that you are running without the benefit of a large testing > community, and you will have to shoulder part of that burden yourself. That would be fine with me. So I wasn't complaining about the ports themselves being broken or even that noone had noticed Keepassx being broken (although that doesn't even build on my machine). When I couldn't get Firefox and Thunderbird to run I googled around a bit to find a solution. All I found out was that the broken port was known for more than a year now. It wasn't a problem that nobody actually fixed it (I know the sparc64 community on FreeBSD is still quite small) but that nobody had marked the ports as broken. My complaint was actually that just about everybody had to find out by themselves that these ports are broken. I was annoying enough for me with a U60 with 450MHz CPUs. I wonder how long it would have taken someone with a much slower machine to "find out". Regards Chris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 12:54:07 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 215BF16A418 for ; Sun, 4 Nov 2007 12:54:07 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 4373D13C4B9; Sun, 4 Nov 2007 12:54:05 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <472DC0EC.3070904@FreeBSD.org> Date: Sun, 04 Nov 2007 13:54:04 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christian Baer References: <200711011822.25884.linimon@lonesome.com> <472DACD7.6040501@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@freebsd.org Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 12:54:07 -0000 Christian Baer wrote: > On Sun, 04 Nov 2007 12:28:23 +0100 Kris Kennaway wrote: > >> ^^^^^ >>> Someone is working on FreeBSD/sparc32? >> FreeBSD does not support 32-bit sparc and it is unlikely it ever will. > > That's why I was a little shocked about the Sun4v. Was that a typo? No, sun4v is the latest sparc architecture. It is very much 64 bit ;) >>> I'm just wondering how two really common apps that have been broken for >>> quite a while now could just slip through the grid. >> Few people use sparc64 on their desktop. That means that if you want to >> do that you are running without the benefit of a large testing >> community, and you will have to shoulder part of that burden yourself. > > That would be fine with me. So I wasn't complaining about the ports > themselves being broken or even that noone had noticed Keepassx being > broken (although that doesn't even build on my machine). > > When I couldn't get Firefox and Thunderbird to run I googled around a bit > to find a solution. All I found out was that the broken port was known for > more than a year now. It wasn't a problem that nobody actually fixed it (I > know the sparc64 community on FreeBSD is still quite small) but that > nobody had marked the ports as broken. My complaint was actually that just > about everybody had to find out by themselves that these ports are broken. > I was annoying enough for me with a U60 with 450MHz CPUs. I wonder how > long it would have taken someone with a much slower machine to "find out". It has been broken and fixed many times over history. That is what I meant by "fragile", i.e. when someone fixes it in one version, later versions tend to become broken again. Kris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 13:37:59 2007 Return-Path: Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6EAE16A41B for ; Sun, 4 Nov 2007 13:37:59 +0000 (UTC) (envelope-from member@ebay.com) Received: from mxphxpool65.ebay.com (mxphxpool65.ebay.com [66.211.161.65]) by mx1.freebsd.org (Postfix) with ESMTP id 66ED113C4A8 for ; Sun, 4 Nov 2007 13:37:59 +0000 (UTC) (envelope-from member@ebay.com) Received: from mxpool20.ebay.com (HELO mx38.sjc.ebay.com) ([66.135.197.26]) by mxphxpool65.ebay.com with ESMTP; 04 Nov 2007 05:26:06 -0800 Received: from rc-v3conta025 (rc-v3conta025.smf.ebay.com [10.9.86.115]) by mx38.sjc.ebay.com (8.13.5/8.13.5) with ESMTP id lA4DPoXH027712 for ; Sun, 4 Nov 2007 06:25:50 -0700 DomainKey-Signature: a=rsa-sha1; s=dksm28; d=ebay.com; c=nofws; q=dns; h=from:reply-to:to:subject:x-ebay-mailtracker: x-ebay-mailversiontracker:mime-version:content-type; b=FslIrQ/GdRT9IZPG9rlxeF9ZJYWpLHlBL5dUjQpVWhAGr6wzKWtmWR7y+EDTkWvt7 uqt7jLHsTGEcuh8Wg5Ntg== Date: Sun, 4 Nov 2007 06:25:50 -0700 Message-Id: <200711041325.lA4DPoXH027712@mx38.sjc.ebay.com> From: eBay To: freebsd-sparc@freebsd.org X-eBay-MailTracker: 11030.537.0.63852 X-eBay-MailVersionTracker: 537.5593657 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ysgeweusuuvsi thought you might like this item on eBay X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: member@ebay.com List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2007 13:37:59 -0000 ----------------------------------------------------------------- An eBay member wants to show you this item ----------------------------------------------------------------- hi friends: Our website is : www.record-saler.com We are a large=20 wholesaler for selling electrical products ,an agent of all the well-known= =20 digital products manufacturers,and facing to wholesalers worldwide.We have= =20 our own warehouse and stores,We export all kinds of digital products, and=20 offer competitive,attractive price and good quality ,so you can make a big= =20 profitwe.we have been received very high praise from our customers all over= =20 the world in the past few years.=20 Please see the details on our website:=20 www.record-saler.com ----- MSN : record-saler@hotmail.com ----- =20 ----- E-mail : record-saler@hotmail.com ----- -----=20 http://www.record-saler.com/productlist.asp?cid=3D10350000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Show me http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&&item=3D190153819395 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Item name: Toshiba REGZA 32HLV67U 32 Current price: PHP 12,196.00=20 End time: Sep-17-07 04:01:28 PDT ----------------------------------------------------------------- Learn how you can protect yourself from spoof (fake) emails at:=20 http://pages.ebay.com/education/spooftutorial/index.html This email sent through the eBay platform from a sender who thinks you are= =20 likely to be interested in this information. eBay takes no liability for=20 sending this email or its content. You can report this message at=20 http://pages.ebay.com/help/policies/rfe-spam-ov.html as unsolicited=20 (spam/spoof) email. Copyright =A9 2007 eBay Inc. All Rights Reserved. Designated trademarks and brands are the property of their respective=20 owners. eBay and the eBay logo are trademarks of eBay Inc. eBay Inc. is located at 2145 Hamilton Avenue, San Jose, CA 95125. From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 14:21:16 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AF0E16A417 for ; Sun, 4 Nov 2007 14:21:16 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from sakima.Ivy.NET (sakima.Ivy.NET [IPv6:2610:1f8:dc:41:220:edff:fe27:e764]) by mx1.freebsd.org (Postfix) with ESMTP id AC7D213C4A3 for ; Sun, 4 Nov 2007 14:21:15 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from castrovalva.Ivy.NET (castrovalva.Ivy.NET [IPv6:2610:1f8:dc:c0::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sakima.Ivy.NET (Postfix) with ESMTP id 5DC13A80E9 for ; Sun, 4 Nov 2007 09:23:02 -0500 (EST) Received: by castrovalva.Ivy.NET (Postfix, from userid 405) id 16FAF12FD0E; Sun, 4 Nov 2007 09:21:14 -0500 (EST) To: freebsd-sparc64@freebsd.org References: From: Miles Nordin MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Sun_Nov__4_09:21:02_2007-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 04 Nov 2007 09:21:12 -0500 In-Reply-To: (Christian Baer's message of "Sun, 4 Nov 2007 11:49:39 +0100 (CET)") Message-ID: User-Agent: T-gnus/6.17.2 (based on No Gnus v0.2) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.4 (alpha--netbsd) MULE/5.0 (SAKAKI) Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 14:21:16 -0000 --pgp-sign-Multipart_Sun_Nov__4_09:21:02_2007-1 Content-Type: text/plain; charset=US-ASCII >>>>> "cb" == Christian Baer writes: cb> Firefox was now a 32bit app in pgksrc. really? How do they do that? First I think you would have to install a whole NetBSD/sparc userland on your NetBSD/sparc64 system, and maintain a /usr/pkg32 so you could install 32-bit versions of all the dependent libraries. Second, I thought the COMPAT_32 stuff was broken for certain basic things like threads so it was impossible to run 64-bit and 32-bit programs under the same kernel. Do you mean some of them are using a NetBSD/sparc(32) kernel on UltraSPARC hardware? --pgp-sign-Multipart_Sun_Nov__4_09:21:02_2007-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iQCVAwUARy3VWInCBbTaW/4dAQKpLAP7BtWGdaQmcG3GdyLuo6gF+v1rYkdANngx W+Cjs/E74Ufq9PN8kl09uwqR9guSj5mlhMaB5vOUuKum6Oozvk0NmuOGLhgguWHt KpGzbugiJ26i/fcQEqBd4s2fm/BN+H63UqPHIvjWFdIsOlJrKXFdLXHO97x5cEPk 7LroiBJG3JA= =/VUh -----END PGP SIGNATURE----- --pgp-sign-Multipart_Sun_Nov__4_09:21:02_2007-1-- From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 15:59:16 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 728EA16A41A for ; Sun, 4 Nov 2007 15:59:16 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from sakima.Ivy.NET (sakima.Ivy.NET [IPv6:2610:1f8:dc:41:220:edff:fe27:e764]) by mx1.freebsd.org (Postfix) with ESMTP id 1010513C4A3 for ; Sun, 4 Nov 2007 15:59:15 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from castrovalva.Ivy.NET (castrovalva.Ivy.NET [IPv6:2610:1f8:dc:c0::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sakima.Ivy.NET (Postfix) with ESMTP id 7ADDAA80E9 for ; Sun, 4 Nov 2007 11:01:02 -0500 (EST) Received: by castrovalva.Ivy.NET (Postfix, from userid 405) id 1A72312FD0E; Sun, 4 Nov 2007 10:59:14 -0500 (EST) To: freebsd-sparc64@freebsd.org References: <200711011822.25884.linimon@lonesome.com> <20071104114811.GA19506@soaustin.net> From: Miles Nordin MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Sun_Nov__4_10:59:13_2007-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 04 Nov 2007 10:59:13 -0500 In-Reply-To: <20071104114811.GA19506@soaustin.net> (Mark Linimon's message of "Sun, 4 Nov 2007 05:48:11 -0600") Message-ID: User-Agent: T-gnus/6.17.2 (based on No Gnus v0.2) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.4 (alpha--netbsd) MULE/5.0 (SAKAKI) Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 15:59:16 -0000 --pgp-sign-Multipart_Sun_Nov__4_10:59:13_2007-1 Content-Type: text/plain; charset=US-ASCII >>>>> "ml" == Mark Linimon writes: ml> FreeBSD is the sum of what its volunteers make of it. well, yes, minus what other volunteers break. :/ --pgp-sign-Multipart_Sun_Nov__4_10:59:13_2007-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iQCVAwUARy3sUYnCBbTaW/4dAQJArAP/U8IL97NREfAjn6SAyMKGeS6bwKiFp8UH uu879t9IJvF0TulkAOyYmE3EdcuFkny9A/3i0FmWgRyxm9k6NlF2wJ9Stg7wGQES 6+Z1OQkq20J5amWdQpHxBzHqgvMTguhTwq2/MIPN6WvvOBLCu6juXtibMLP4Pkm+ XVZHTZj6P6g= =GeRd -----END PGP SIGNATURE----- --pgp-sign-Multipart_Sun_Nov__4_10:59:13_2007-1-- From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 16:17:21 2007 Return-Path: Delivered-To: sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B76AA16A41B; Sun, 4 Nov 2007 16:17:21 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 12C3413C4B0; Sun, 4 Nov 2007 16:17:20 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <472DF090.8070904@FreeBSD.org> Date: Sun, 04 Nov 2007 17:17:20 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: sparc64@FreeBSD.org, kib@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: trap from DEBUG_LOCKS 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: Sun, 04 Nov 2007 16:17:21 -0000 The insta-panic at boot on sparc64 with RELENG_7 seems to be fixed, but at the point when it mounts root I get the following panic when DEBUG_LOCKS is enabled: panic: trap: memory address not aligned cpuid = 9 KDB: enter: panic [thread pid 1 tid 100006 ] Stopped at kdb_enter+0x68: ta %xcc, 1 db> wh Tracing pid 1 tid 100006 td 0xfffff800020709c0 panic() at panic+0x204 trap() at trap+0x56c -- memory address not aligned sfar=0xe2f47c27 sfsr=0x40029 %o7=0xc03cd524 -- stack_save() at stack_save+0x18 _lockmgr() at _lockmgr+0x4c vfs_busy() at vfs_busy+0x1d4 vfs_mount_alloc() at vfs_mount_alloc+0x58 vfs_mountroot() at vfs_mountroot+0x2e4 start_init() at start_init+0x58 fork_exit() at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 Kris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 16:18:36 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0477016A419 for ; Sun, 4 Nov 2007 16:18:36 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 5171713C4CC; Sun, 4 Nov 2007 16:18:35 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <472DF0DA.7090401@FreeBSD.org> Date: Sun, 04 Nov 2007 17:18:34 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Miles Nordin References: <200711011822.25884.linimon@lonesome.com> <20071104114811.GA19506@soaustin.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@freebsd.org Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 16:18:36 -0000 Miles Nordin wrote: >>>>>> "ml" == Mark Linimon writes: > > ml> FreeBSD is the sum of what its volunteers make of it. > > well, yes, minus what other volunteers break. :/ Sorry, what was your point? Kris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 16:38:27 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A592716A46B for ; Sun, 4 Nov 2007 16:38:27 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from sakima.Ivy.NET (sakima.Ivy.NET [IPv6:2610:1f8:dc:41:220:edff:fe27:e764]) by mx1.freebsd.org (Postfix) with ESMTP id 3AD4013C48D for ; Sun, 4 Nov 2007 16:38:27 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from castrovalva.Ivy.NET (castrovalva.Ivy.NET [IPv6:2610:1f8:dc:c0::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sakima.Ivy.NET (Postfix) with ESMTP id 934B3A80E9 for ; Sun, 4 Nov 2007 11:40:14 -0500 (EST) Received: by castrovalva.Ivy.NET (Postfix, from userid 405) id 3812B12FD0E; Sun, 4 Nov 2007 11:38:26 -0500 (EST) To: freebsd-sparc64@freebsd.org References: <200711011822.25884.linimon@lonesome.com> <20071104114811.GA19506@soaustin.net> <472DF0DA.7090401@FreeBSD.org> From: Miles Nordin MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Sun_Nov__4_11:38:24_2007-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 04 Nov 2007 11:38:26 -0500 In-Reply-To: <472DF0DA.7090401@FreeBSD.org> (Kris Kennaway's message of "Sun, 04 Nov 2007 17:18:34 +0100") Message-ID: User-Agent: T-gnus/6.17.2 (based on No Gnus v0.2) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.4 (alpha--netbsd) MULE/5.0 (SAKAKI) Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 16:38:27 -0000 --pgp-sign-Multipart_Sun_Nov__4_11:38:24_2007-1 Content-Type: text/plain; charset=US-ASCII >>>>> "kk" == Kris Kennaway writes: kk> Sorry, what was your point? When you work on a marginalized project that has to interface with others, like FreeBSD/sparc64 with FreeBSD/i386, or like BSD ports/pkgsrc with the Linux-centric mainstream of free Unix software, in practice your work is not ``what interests you'' or ``scratching an itch'' or ``what you make of it''---larger and larger chunks of your agenda get chosen by what the dominant project is breaking. It interests some random guy to rototill libcairo for some reason which he finds interesting, and which I would probably find silly if I knew what it was. And that's fine because we all work on our interests, right? But it interests NetBSD's Michael Lorenz to run X11 on Creator3D framebuffers, so does that mean he gets to learn how Creator3D works and write drivers for it? Somewhat, but more so it means he gets to spend his time frantically following around randomguy with a dustpan and cleaning up everything he breaks. If you've done this, you know very well what it's like---the fastest way is often to go through the commit log looking for impatient- or confused-sounding messages from i386-centric people, or just changes in general, and ask, ``could this be it?'' People working on the dominant architecture will say ``I don't have a sparc64'' or ``I don't have a FreeBSD box,'' which means to them more-or-less ``I don't have to worry about what I break here, because after all, how could I?'' Yes, it's always going to be like that somewhat. No, these people who are breaking things definitely aren't bad or necessarily even doing anything wrong. But it's not just an ``we're all volunteers so no one can complain about anything'' situation. It's a software engineering problem, and certain habits, best-practices, social pressures absolutely will influence how much you have this problem, and the ``we're all volunteers'' mantra I think sometimes squashes that process before it can begin. --pgp-sign-Multipart_Sun_Nov__4_11:38:24_2007-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iQCVAwUARy31gonCBbTaW/4dAQKwpgP/Rzi5sRci17wc+2t+STnVnioxg/6VJ4ab iQWmt7f3HpKKjY8+5Ip045b8LXyPyroiPnpWc+8ldopR7NqlP9rf/SwpexBObPRr BiQzfWkzkdImEeDuxMZ9S19EyI1bFH7jQ23Kw6AlpSEo2wru/ZYT6xxG4StricV5 poPCypbitE8= =jJkw -----END PGP SIGNATURE----- --pgp-sign-Multipart_Sun_Nov__4_11:38:24_2007-1-- From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 17:06:34 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3579016A468; Sun, 4 Nov 2007 17:06:34 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 48EAA13C4BF; Sun, 4 Nov 2007 17:06:33 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <472DFC18.3080000@FreeBSD.org> Date: Sun, 04 Nov 2007 18:06:32 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Marius Strobl References: <46FEADFD.8020105@FreeBSD.org> <20071003132944.GA17342@alchemy.franken.de> <200710060222.31023.jhb@freebsd.org> <20071006132620.GF24840@alchemy.franken.de> In-Reply-To: <20071006132620.GF24840@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@freebsd.org Subject: Re: 7.0 broken on e4500 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: Sun, 04 Nov 2007 17:06:34 -0000 Marius Strobl wrote: > On Sat, Oct 06, 2007 at 02:22:30AM -0400, John Baldwin wrote: >> On Wednesday 03 October 2007 09:29:44 am Marius Strobl wrote: >>> On Sat, Sep 29, 2007 at 09:56:45PM +0200, Kris Kennaway wrote: >>>> I get this early during boot with a CVS kernel (updated from last >> December): >>>>> FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs >>>>> panic: tsb_tte_enter: replacing valid kernel mapping >>>>> cpuid = 0 >>>>> KDB: enter: panic >>>>> [thread pid 0 tid 0 ] >>>>> Stopped at kdb_enter+0x68: ta %xcc, 1 >>>>> db> wh >>>>> Tracing pid 0 tid 0 td 0xc0744f80 >>>>> panic() at panic+0x204 >>>>> tsb_tte_enter() at tsb_tte_enter+0xdc >>>>> pmap_enter_locked() at pmap_enter_locked+0x2d0 >>>>> pmap_enter() at pmap_enter+0x64 >>>>> kmem_malloc() at kmem_malloc+0x6e0 >>>>> page_alloc() at page_alloc+0x28 >>>>> uma_large_malloc() at uma_large_malloc+0x44 >>>>> malloc() at malloc+0x1b0 >>>>> sf_buf_init() at sf_buf_init+0xf8 >>>>> mi_startup() at mi_startup+0x18c >>>>> btext() at btext+0x34 >>> Do you by chance load the new kernel manually via the loader >>> prompt, with the old kernel being <= 8MB in size and the new >>> one > 8MB? >> I get this panic on an E220R at work, but my "new" kernel is smaller. >> > > If the actual panic string is "vm_phys_paddr_to_vm_page: paddr > is not in any segment" than that's the problem I had in mind when > replying to Kris but unfortunately failed to describe the right > way around. > >>> ll /boot/kernel/kernel* /boot/test/kernel* >> -r-xr-xr-x 1 root wheel 7821094 Feb 6 2007 /boot/kernel/kernel >> -r-xr-xr-x 1 root wheel 13902501 Feb 6 2007 /boot/kernel/kernel.symbols >> -r-xr-xr-x 1 root wheel 4534968 Oct 6 00:20 /boot/test/kernel >> -r-xr-xr-x 1 root wheel 10101980 Oct 6 00:20 /boot/test/kernel.symbols >> >> The working kernel (~7MB) is the GENERIC kernel, and the "test" kernel >> is the stripped down kernel for this machine. In my case I'm panicing in >> pmap_remove_tte() called from pmap_enter_locked(). I added some KTR traces >> to the pmap code to try and investigate, but I'm guessing the root problem is >> that the loader doesn't properly handle telling OFW about needing to change >> the mappings when unloading and then loading a new kernel? >> >> Hmm, it looks like currently the loader doesn't do any sort of MD callback >> when unloading a file, so the loader isn't going to free up the RAM it asked >> for from OFW for the old kernel. >> > > Correct, the immediate problem (which I had a patch for somewhere) > is that in case the "old" kernel required more TLB slots to be used > than the "new" one one can't use the kernel end in order to determine > how many slots are used for the kernel map. As you describe the real > problem lies within the loader though. The funny thing is that no > arch except sparc64 and sun4v seems to rely on the kernel end > provided by the loader. > If no idea what's the cause of the problem Kris is seeing though. > > Marius > > FYI one of the e4500's is now booting again but another is still failing with the same panic: FreeBSD 8.0-CURRENT #44: Mon Nov 5 01:52:42 JST 2007 root@e4500-2.allbsd.org:/usr/src/sys/sparc64/compile/E4500_2 real memory = 9663676416 (9216 MB) avail memory = 9433554944 (8996 MB) cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) cpu1: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) cpu2: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) cpu3: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) cpu4: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) cpu5: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) cpu6: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) cpu7: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) cpu8: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) cpu9: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs panic: tsb_tte_enter: replacing valid kernel mapping db> wh Tracing pid 0 tid 0 td 0xc056ad30 panic() at panic+0x248 tsb_tte_enter() at tsb_tte_enter+0xdc pmap_enter_locked() at pmap_enter_locked+0x318 pmap_enter() at pmap_enter+0x64 kmem_malloc() at kmem_malloc+0x644 page_alloc() at page_alloc+0x28 uma_large_malloc() at uma_large_malloc+0x44 malloc() at malloc+0x1a0 sf_buf_init() at sf_buf_init+0xe8 mi_startup() at mi_startup+0x1e8 btext() at btext+0x34 Kris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 17:25:28 2007 Return-Path: Delivered-To: sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DE9216A419; Sun, 4 Nov 2007 17:25:28 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id F314113C4AC; Sun, 4 Nov 2007 17:25:27 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <472E0087.2000209@FreeBSD.org> Date: Sun, 04 Nov 2007 18:25:27 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: sparc64@FreeBSD.org, scottl@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: panic: mutex isp not owned at ../../../kern/kern_mutex.c:206 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: Sun, 04 Nov 2007 17:25:28 -0000 Another panic when booting an e4500 running CURRENT: sbus0: mem 0x10000-0x20017 irq 162 type socal (no driver attached) isp0 mem 0x10000-0x1044f irq 139 on sbus0 isp0: [ITHREAD] panic: mutex isp not owned at ../../../kern/kern_mutex.c:206 cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x68: ta %xcc, 1 db> wh Tracing pid 0 tid 0 td 0xc0749280 panic() at panic+0x204 _mtx_assert() at _mtx_assert+0xac _mtx_unlock_flags() at _mtx_unlock_flags+0x12c isp_sbus_mbxdma() at isp_sbus_mbxdma+0x38 isp_reset() at isp_reset+0x214 isp_sbus_attach() at isp_sbus_attach+0x7a0 device_attach() at device_attach+0x4a4 device_probe_and_attach() at device_probe_and_attach+0x188 bus_generic_attach() at bus_generic_attach+0x10 sbus_attach() at sbus_attach+0x111c device_attach() at device_attach+0x4a4 device_probe_and_attach() at device_probe_and_attach+0x188 bus_generic_attach() at bus_generic_attach+0x10 nexus_attach() at nexus_attach+0x4fc device_attach() at device_attach+0x4a4 device_probe_and_attach() at device_probe_and_attach+0x188 root_bus_configure() at root_bus_configure+0x28 configure() at configure+0x4 mi_startup() at mi_startup+0x18c btext() at btext+0x34 Kris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 19:34:37 2007 Return-Path: Delivered-To: sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C961A16A418; Sun, 4 Nov 2007 19:34:37 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 7ECCA13C4B3; Sun, 4 Nov 2007 19:34:37 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lA4HioDQ031979; Sun, 4 Nov 2007 10:44:50 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <472E04F5.3030300@samsco.org> Date: Sun, 04 Nov 2007 10:44:21 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Kris Kennaway References: <472E0087.2000209@FreeBSD.org> In-Reply-To: <472E0087.2000209@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sun, 04 Nov 2007 10:44:50 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: sparc64@FreeBSD.org Subject: Re: panic: mutex isp not owned at ../../../kern/kern_mutex.c:206 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: Sun, 04 Nov 2007 19:34:37 -0000 Thanks, I'll look at it. Scott Kris Kennaway wrote: > Another panic when booting an e4500 running CURRENT: > > sbus0: mem 0x10000-0x20017 irq 162 type socal (no driver > attached) > isp0 mem 0x10000-0x1044f irq 139 on sbus0 > isp0: [ITHREAD] > panic: mutex isp not owned at ../../../kern/kern_mutex.c:206 > cpuid = 0 > KDB: enter: panic > [thread pid 0 tid 0 ] > Stopped at kdb_enter+0x68: ta %xcc, 1 > db> wh > Tracing pid 0 tid 0 td 0xc0749280 > panic() at panic+0x204 > _mtx_assert() at _mtx_assert+0xac > _mtx_unlock_flags() at _mtx_unlock_flags+0x12c > isp_sbus_mbxdma() at isp_sbus_mbxdma+0x38 > isp_reset() at isp_reset+0x214 > isp_sbus_attach() at isp_sbus_attach+0x7a0 > device_attach() at device_attach+0x4a4 > device_probe_and_attach() at device_probe_and_attach+0x188 > bus_generic_attach() at bus_generic_attach+0x10 > sbus_attach() at sbus_attach+0x111c > device_attach() at device_attach+0x4a4 > device_probe_and_attach() at device_probe_and_attach+0x188 > bus_generic_attach() at bus_generic_attach+0x10 > nexus_attach() at nexus_attach+0x4fc > device_attach() at device_attach+0x4a4 > device_probe_and_attach() at device_probe_and_attach+0x188 > root_bus_configure() at root_bus_configure+0x28 > configure() at configure+0x4 > mi_startup() at mi_startup+0x18c > btext() at btext+0x34 > > Kris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 20:51:06 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED80016A419 for ; Sun, 4 Nov 2007 20:51:06 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id D014413C48D for ; Sun, 4 Nov 2007 20:51:06 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 02E1D8C0BA; Sun, 4 Nov 2007 14:31:44 -0600 (CST) Date: Sun, 4 Nov 2007 14:31:44 -0600 To: Miles Nordin Message-ID: <20071104203144.GA30608@soaustin.net> References: <200711011822.25884.linimon@lonesome.com> <20071104114811.GA19506@soaustin.net> <472DF0DA.7090401@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) Cc: freebsd-sparc64@freebsd.org Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 20:51:07 -0000 On Sun, Nov 04, 2007 at 11:38:26AM -0500, Miles Nordin wrote: > People working on the dominant architecture will say ``I don't have > a sparc64'' or ``I don't have a FreeBSD box,'' which means to them > more-or-less ``I don't have to worry about what I break here, because > after all, how could I?'' And thus, your recommendation is? [fwiw, Kris has probably done more to keep ports going on sparc64 than anyone else in the project, in terms of running package builds, identifying problems, emailing maintainers, and marking things broken when they don't install/deinstall cleanly. This is also true for the other architectures :-) ] The point that I'm trying to make is that it's easier to address specific problems than general ones. If you want things fixed, you're going to need to be proactive in identifying sources of breakage and notifying the people that caused them, whether that's via email or send-pr. mcl From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 22:19:33 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59E2916A419; Sun, 4 Nov 2007 22:19:33 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 42BA613C4B3; Sun, 4 Nov 2007 22:19:32 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <472E4573.3090708@FreeBSD.org> Date: Sun, 04 Nov 2007 23:19:31 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kris Kennaway References: <46FEADFD.8020105@FreeBSD.org> <20071003132944.GA17342@alchemy.franken.de> <200710060222.31023.jhb@freebsd.org> <20071006132620.GF24840@alchemy.franken.de> <472DFC18.3080000@FreeBSD.org> In-Reply-To: <472DFC18.3080000@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@freebsd.org, Marius Strobl Subject: Re: 7.0 broken on e4500 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: Sun, 04 Nov 2007 22:19:33 -0000 Kris Kennaway wrote: > Marius Strobl wrote: >> On Sat, Oct 06, 2007 at 02:22:30AM -0400, John Baldwin wrote: >>> On Wednesday 03 October 2007 09:29:44 am Marius Strobl wrote: >>>> On Sat, Sep 29, 2007 at 09:56:45PM +0200, Kris Kennaway wrote: >>>>> I get this early during boot with a CVS kernel (updated from last >>> December): >>>>>> FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs >>>>>> panic: tsb_tte_enter: replacing valid kernel mapping >>>>>> cpuid = 0 >>>>>> KDB: enter: panic >>>>>> [thread pid 0 tid 0 ] >>>>>> Stopped at kdb_enter+0x68: ta %xcc, 1 >>>>>> db> wh >>>>>> Tracing pid 0 tid 0 td 0xc0744f80 >>>>>> panic() at panic+0x204 >>>>>> tsb_tte_enter() at tsb_tte_enter+0xdc >>>>>> pmap_enter_locked() at pmap_enter_locked+0x2d0 >>>>>> pmap_enter() at pmap_enter+0x64 >>>>>> kmem_malloc() at kmem_malloc+0x6e0 >>>>>> page_alloc() at page_alloc+0x28 >>>>>> uma_large_malloc() at uma_large_malloc+0x44 >>>>>> malloc() at malloc+0x1b0 >>>>>> sf_buf_init() at sf_buf_init+0xf8 >>>>>> mi_startup() at mi_startup+0x18c >>>>>> btext() at btext+0x34 >>>> Do you by chance load the new kernel manually via the loader >>>> prompt, with the old kernel being <= 8MB in size and the new >>>> one > 8MB? >>> I get this panic on an E220R at work, but my "new" kernel is smaller. >>> >> >> If the actual panic string is "vm_phys_paddr_to_vm_page: paddr >> is not in any segment" than that's the problem I had in mind when >> replying to Kris but unfortunately failed to describe the right >> way around. >> >>>> ll /boot/kernel/kernel* /boot/test/kernel* >>> -r-xr-xr-x 1 root wheel 7821094 Feb 6 2007 /boot/kernel/kernel >>> -r-xr-xr-x 1 root wheel 13902501 Feb 6 2007 >>> /boot/kernel/kernel.symbols >>> -r-xr-xr-x 1 root wheel 4534968 Oct 6 00:20 /boot/test/kernel >>> -r-xr-xr-x 1 root wheel 10101980 Oct 6 00:20 >>> /boot/test/kernel.symbols >>> >>> The working kernel (~7MB) is the GENERIC kernel, and the "test" kernel >>> is the stripped down kernel for this machine. In my case I'm >>> panicing in pmap_remove_tte() called from pmap_enter_locked(). I >>> added some KTR traces to the pmap code to try and investigate, but >>> I'm guessing the root problem is that the loader doesn't properly >>> handle telling OFW about needing to change the mappings when >>> unloading and then loading a new kernel? >>> >>> Hmm, it looks like currently the loader doesn't do any sort of MD >>> callback >>> when unloading a file, so the loader isn't going to free up the RAM >>> it asked for from OFW for the old kernel. >>> >> >> Correct, the immediate problem (which I had a patch for somewhere) >> is that in case the "old" kernel required more TLB slots to be used >> than the "new" one one can't use the kernel end in order to determine >> how many slots are used for the kernel map. As you describe the real >> problem lies within the loader though. The funny thing is that no >> arch except sparc64 and sun4v seems to rely on the kernel end >> provided by the loader. >> If no idea what's the cause of the problem Kris is seeing though. >> >> Marius >> >> > > FYI one of the e4500's is now booting again but another is still failing > with the same panic: > > FreeBSD 8.0-CURRENT #44: Mon Nov 5 01:52:42 JST 2007 > root@e4500-2.allbsd.org:/usr/src/sys/sparc64/compile/E4500_2 > real memory = 9663676416 (9216 MB) > avail memory = 9433554944 (8996 MB) > cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > cpu1: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > cpu2: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > cpu3: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > cpu4: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > cpu5: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > cpu6: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > cpu7: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > cpu8: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > cpu9: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs > panic: tsb_tte_enter: replacing valid kernel mapping > db> wh > Tracing pid 0 tid 0 td 0xc056ad30 > panic() at panic+0x248 > tsb_tte_enter() at tsb_tte_enter+0xdc > pmap_enter_locked() at pmap_enter_locked+0x318 > pmap_enter() at pmap_enter+0x64 > kmem_malloc() at kmem_malloc+0x644 > page_alloc() at page_alloc+0x28 > uma_large_malloc() at uma_large_malloc+0x44 > malloc() at malloc+0x1a0 > sf_buf_init() at sf_buf_init+0xe8 > mi_startup() at mi_startup+0x1e8 > btext() at btext+0x34 > > Kris > Another runtime panic from a u60: panic() at panic+0x204 _mtx_assert() at _mtx_assert+0xac pmap_page_is_mapped() at pmap_page_is_mapped+0x38 vm_page_free_toq() at vm_page_free_toq+0x4c vm_page_free() at vm_page_free+0x10 uma_small_free() at uma_small_free+0x1c zone_drain() at zone_drain+0x2d0 zone_foreach() at zone_foreach+0x6c uma_reclaim() at uma_reclaim+0x20 vm_pageout() at vm_pageout+0x9b8 fork_exit() at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 Kris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 22:45:32 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F9D716A421; Sun, 4 Nov 2007 22:45:32 +0000 (UTC) (envelope-from royce@alaska.net) Received: from malik.acsalaska.net (malik.acsalaska.net [209.112.173.227]) by mx1.freebsd.org (Postfix) with ESMTP id B357E13C48E; Sun, 4 Nov 2007 22:45:29 +0000 (UTC) (envelope-from royce@alaska.net) Received: from [192.168.254.100] (209-112-218-167-rb1.nwc.dsl.dynamic.acsalaska.net [209.112.218.167]) by malik.acsalaska.net (8.14.1/8.14.1) with ESMTP id lA4MjCOI011769; Sun, 4 Nov 2007 13:45:12 -0900 (AKST) (envelope-from royce@alaska.net) Message-ID: <472E4B8D.2020902@alaska.net> Date: Sun, 04 Nov 2007 13:45:33 -0900 From: Royce Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Kris Kennaway References: <200711011822.25884.linimon@lonesome.com> <472B39A8.3070708@alaska.net> <472DAFBE.9070603@FreeBSD.org> In-Reply-To: <472DAFBE.9070603@FreeBSD.org> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.63; SA 3.2.3; spamdefang 1.122 Cc: Mark Linimon , freebsd-sparc64@freebsd.org Subject: hardware and package builds (was: Re: Doesn't anything work around here?) 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: Sun, 04 Nov 2007 22:45:32 -0000 Kris Kennaway wrote, on 11/4/2007 2:40 AM: > That is no problem, even on single CPU machines I run concurrent builds > since it turns out to be more efficient. In the past we have even used > 14 CPU e4500 machines for package builds although they all died from > hardware failure. I'd like to put some time and money where my mouth is on package builds. To summarize a couple of threads and off-list exchanges: - A 4x 450MHz Ultra 80 would be good for sparc64 package builds, and all of the CPUs would be useful. - There are more machines used by the project than there is space to comfortably host them, so remote hosting is needed. - If more packages were working and built more often, and if freebsd-update was available for sparc64, the overall "health" of the platform would be improved. Based on the above, here are some proposed actions and associated questions. System: I am willing to buy a 4x U80 for myself and make it available to the project for package builds. Shipping to Alaska is a bear, so once the deal goes down, if any other donors could chip in to get it shipped here, I would appreciate it. I don't want to do this, however, unless it will actually be useful -- and used. Will it? Alternate system: IIRC from a couple of years ago, the unsupported onboard SCSI controller in my Ex500 machines prevented me from easily making them available to the project. What is the status of the needed (esp?) driver port from NetBSD? Disk: How much disk will be needed for package builds, and what configuration will reduce turnaround time? Remote access: I will ask my employer if we can host the U80 on work premises and provide remote access. Kris, I assume that your needs haven't changed since this post? http://lists.freebsd.org/mailman/htdig/freebsd-sparc64/2004-August/001961.html Load/use: How much daily/hourly load would the system see? I assume that ports are built on a rolling basis (as they're updated) between release cycles, and that there's a big push to prepare an entire package set for a given release? Tools: I've only just now discovered and started to try to grok ports/Tools/portbuild/scripts/*, so I have some catching up to do to even understand scope here. What other recommended reading is there? Royce -- Royce D. Williams - IP Engineering, ACS http://www.tycho.org/royce/ - PGP: 3FC087DB/1776A531 You can never tell what a programmer is doing 'til it's too late ~Cray From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 23:12:26 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F4F816A417; Sun, 4 Nov 2007 23:12:26 +0000 (UTC) (envelope-from royce@alaska.net) Received: from hermes.acsalaska.net (hermes.acsalaska.net [209.112.173.230]) by mx1.freebsd.org (Postfix) with ESMTP id 3095D13C4B2; Sun, 4 Nov 2007 23:12:25 +0000 (UTC) (envelope-from royce@alaska.net) Received: from [192.168.254.100] (209-112-218-167-rb1.nwc.dsl.dynamic.acsalaska.net [209.112.218.167]) by hermes.acsalaska.net (8.14.1/8.14.1) with ESMTP id lA4NCDfY049372; Sun, 4 Nov 2007 14:12:13 -0900 (AKST) (envelope-from royce@alaska.net) Message-ID: <472E51E2.7060402@alaska.net> Date: Sun, 04 Nov 2007 14:12:34 -0900 From: Royce Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Kris Kennaway References: <200711011822.25884.linimon@lonesome.com> <472B39A8.3070708@alaska.net> <472DAFBE.9070603@FreeBSD.org> <472E4B8D.2020902@alaska.net> In-Reply-To: <472E4B8D.2020902@alaska.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.63; SA 3.2.3; spamdefang 1.122 Cc: Mark Linimon , freebsd-sparc64@freebsd.org Subject: Re: hardware and package builds 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: Sun, 04 Nov 2007 23:12:26 -0000 Royce Williams wrote, on 11/4/2007 1:45 PM: > Tools: I've only just now discovered and started to try to grok > ports/Tools/portbuild/scripts/*, so I have some catching up to do to > even understand scope here. What other recommended reading is there? Er ... Google is my friend. Reading articles/portbuild now. Royce -- Royce D. Williams - IP Engineering, ACS http://www.tycho.org/royce/ - PGP: 3FC087DB/1776A531 Let him who would move the world first move himself. - Socrates From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 23:23:44 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0780016A41B for ; Sun, 4 Nov 2007 23:23:44 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 2073213C48A; Sun, 4 Nov 2007 23:23:42 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <472E547E.8020104@FreeBSD.org> Date: Mon, 05 Nov 2007 00:23:42 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Royce Williams References: <200711011822.25884.linimon@lonesome.com> <472B39A8.3070708@alaska.net> <472DAFBE.9070603@FreeBSD.org> <472E4B8D.2020902@alaska.net> In-Reply-To: <472E4B8D.2020902@alaska.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Linimon , freebsd-sparc64@freebsd.org Subject: Re: hardware and package builds 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: Sun, 04 Nov 2007 23:23:44 -0000 Royce Williams wrote: > Kris Kennaway wrote, on 11/4/2007 2:40 AM: >> That is no problem, even on single CPU machines I run concurrent builds >> since it turns out to be more efficient. In the past we have even used >> 14 CPU e4500 machines for package builds although they all died from >> hardware failure. > > I'd like to put some time and money where my mouth is on package builds. > > To summarize a couple of threads and off-list exchanges: > > - A 4x 450MHz Ultra 80 would be good for sparc64 package builds, and > all of the CPUs would be useful. > > - There are more machines used by the project than there is space to > comfortably host them, so remote hosting is needed. > > - If more packages were working and built more often, and if > freebsd-update was available for sparc64, the overall "health" of the > platform would be improved. > > > Based on the above, here are some proposed actions and associated > questions. > > System: I am willing to buy a 4x U80 for myself and make it available > to the project for package builds. Shipping to Alaska is a bear, so > once the deal goes down, if any other donors could chip in to get it > shipped here, I would appreciate it. I don't want to do this, > however, unless it will actually be useful -- and used. Will it? All other factors being satisfied, yes. > Alternate system: IIRC from a couple of years ago, the unsupported > onboard SCSI controller in my Ex500 machines prevented me from easily > making them available to the project. What is the status of the > needed (esp?) driver port from NetBSD? Yeah esp has been supported for several years now, and I have personal experience with e4500 systems. > Disk: How much disk will be needed for package builds, and what > configuration will reduce turnaround time? The build machines should have at least 20GB, preferably 40GB or so. Much larger amounts of disk will not be efficiently used. To cut down on network traffic, somewhere local to the machine should be an FTP mirror which would be configured to mirror a distfiles tree. > Remote access: I will ask my employer if we can host the U80 on work > premises and provide remote access. Kris, I assume that your needs > haven't changed since this post? > > http://lists.freebsd.org/mailman/htdig/freebsd-sparc64/2004-August/001961.html Basically, yes. The current status of FreeBSD/sparc64 appears to be somewhat degraded, so it is likely that frequent reboots and/or kernel debugging may be needed. That will be easiest accomplished if there is at least a serial console available remotely. > Load/use: How much daily/hourly load would the system see? I assume > that ports are built on a rolling basis (as they're updated) between > release cycles, and that there's a big push to prepare an entire > package set for a given release? They are built continuously, so the machine would be in use basically 24/7. Sometimes there are delays when one package set finishes building and before another one starts, but we try to minimize that downtime. > Tools: I've only just now discovered and started to try to grok > ports/Tools/portbuild/scripts/*, so I have some catching up to do to > even understand scope here. What other recommended reading is there? There is an article in the website documentation that gives some overview of how these scripts are used. Mark also has private notes about the care and feeding of the build system, but I don't know if these are ready for sharing. Kris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 23:25:06 2007 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2423916A41B; Sun, 4 Nov 2007 23:25:06 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 04C6213C4A8; Sun, 4 Nov 2007 23:25:04 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <472E54D0.8070807@FreeBSD.org> Date: Mon, 05 Nov 2007 00:25:04 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Marius Strobl References: <46FEADFD.8020105@FreeBSD.org> <20071003132944.GA17342@alchemy.franken.de> <200710060222.31023.jhb@freebsd.org> <20071006132620.GF24840@alchemy.franken.de> <472DFC18.3080000@FreeBSD.org> <472E4573.3090708@FreeBSD.org> <20071104224618.GD36824@alchemy.franken.de> In-Reply-To: <20071104224618.GD36824@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@FreeBSD.org, freebsd-sparc64@FreeBSD.org, John Baldwin Subject: Re: 7.0 broken on e4500 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: Sun, 04 Nov 2007 23:25:06 -0000 Marius Strobl wrote: > On Sun, Nov 04, 2007 at 11:19:31PM +0100, Kris Kennaway wrote: >> Kris Kennaway wrote: >>> Marius Strobl wrote: >>>> On Sat, Oct 06, 2007 at 02:22:30AM -0400, John Baldwin wrote: >>>>> On Wednesday 03 October 2007 09:29:44 am Marius Strobl wrote: >>>>>> On Sat, Sep 29, 2007 at 09:56:45PM +0200, Kris Kennaway wrote: >>>>>>> I get this early during boot with a CVS kernel (updated from last >>>>> December): >>>>>>>> FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs >>>>>>>> panic: tsb_tte_enter: replacing valid kernel mapping >>>>>>>> cpuid = 0 >>>>>>>> KDB: enter: panic >>>>>>>> [thread pid 0 tid 0 ] >>>>>>>> Stopped at kdb_enter+0x68: ta %xcc, 1 >>>>>>>> db> wh >>>>>>>> Tracing pid 0 tid 0 td 0xc0744f80 >>>>>>>> panic() at panic+0x204 >>>>>>>> tsb_tte_enter() at tsb_tte_enter+0xdc >>>>>>>> pmap_enter_locked() at pmap_enter_locked+0x2d0 >>>>>>>> pmap_enter() at pmap_enter+0x64 >>>>>>>> kmem_malloc() at kmem_malloc+0x6e0 >>>>>>>> page_alloc() at page_alloc+0x28 >>>>>>>> uma_large_malloc() at uma_large_malloc+0x44 >>>>>>>> malloc() at malloc+0x1b0 >>>>>>>> sf_buf_init() at sf_buf_init+0xf8 >>>>>>>> mi_startup() at mi_startup+0x18c >>>>>>>> btext() at btext+0x34 >>>>>> Do you by chance load the new kernel manually via the loader >>>>>> prompt, with the old kernel being <= 8MB in size and the new >>>>>> one > 8MB? >>>>> I get this panic on an E220R at work, but my "new" kernel is smaller. >>>>> >>>> If the actual panic string is "vm_phys_paddr_to_vm_page: paddr >>>> is not in any segment" than that's the problem I had in mind when >>>> replying to Kris but unfortunately failed to describe the right >>>> way around. >>>> >>>>>> ll /boot/kernel/kernel* /boot/test/kernel* >>>>> -r-xr-xr-x 1 root wheel 7821094 Feb 6 2007 /boot/kernel/kernel >>>>> -r-xr-xr-x 1 root wheel 13902501 Feb 6 2007 >>>>> /boot/kernel/kernel.symbols >>>>> -r-xr-xr-x 1 root wheel 4534968 Oct 6 00:20 /boot/test/kernel >>>>> -r-xr-xr-x 1 root wheel 10101980 Oct 6 00:20 >>>>> /boot/test/kernel.symbols >>>>> >>>>> The working kernel (~7MB) is the GENERIC kernel, and the "test" kernel >>>>> is the stripped down kernel for this machine. In my case I'm >>>>> panicing in pmap_remove_tte() called from pmap_enter_locked(). I >>>>> added some KTR traces to the pmap code to try and investigate, but >>>>> I'm guessing the root problem is that the loader doesn't properly >>>>> handle telling OFW about needing to change the mappings when >>>>> unloading and then loading a new kernel? >>>>> >>>>> Hmm, it looks like currently the loader doesn't do any sort of MD >>>>> callback >>>>> when unloading a file, so the loader isn't going to free up the RAM >>>>> it asked for from OFW for the old kernel. >>>>> >>>> Correct, the immediate problem (which I had a patch for somewhere) >>>> is that in case the "old" kernel required more TLB slots to be used >>>> than the "new" one one can't use the kernel end in order to determine >>>> how many slots are used for the kernel map. As you describe the real >>>> problem lies within the loader though. The funny thing is that no >>>> arch except sparc64 and sun4v seems to rely on the kernel end >>>> provided by the loader. >>>> If no idea what's the cause of the problem Kris is seeing though. >>>> >>>> Marius >>>> >>>> >>> FYI one of the e4500's is now booting again but another is still failing >>> with the same panic: >>> >>> FreeBSD 8.0-CURRENT #44: Mon Nov 5 01:52:42 JST 2007 >>> root@e4500-2.allbsd.org:/usr/src/sys/sparc64/compile/E4500_2 >>> real memory = 9663676416 (9216 MB) >>> avail memory = 9433554944 (8996 MB) >>> cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>> cpu1: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>> cpu2: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>> cpu3: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>> cpu4: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>> cpu5: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>> cpu6: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>> cpu7: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>> cpu8: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>> cpu9: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>> FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs >>> panic: tsb_tte_enter: replacing valid kernel mapping >>> db> wh >>> Tracing pid 0 tid 0 td 0xc056ad30 >>> panic() at panic+0x248 >>> tsb_tte_enter() at tsb_tte_enter+0xdc >>> pmap_enter_locked() at pmap_enter_locked+0x318 >>> pmap_enter() at pmap_enter+0x64 >>> kmem_malloc() at kmem_malloc+0x644 >>> page_alloc() at page_alloc+0x28 >>> uma_large_malloc() at uma_large_malloc+0x44 >>> malloc() at malloc+0x1a0 >>> sf_buf_init() at sf_buf_init+0xe8 >>> mi_startup() at mi_startup+0x1e8 >>> btext() at btext+0x34 >>> >>> Kris >>> >> Another runtime panic from a u60: >> >> panic() at panic+0x204 >> _mtx_assert() at _mtx_assert+0xac >> pmap_page_is_mapped() at pmap_page_is_mapped+0x38 >> vm_page_free_toq() at vm_page_free_toq+0x4c >> vm_page_free() at vm_page_free+0x10 >> uma_small_free() at uma_small_free+0x1c >> zone_drain() at zone_drain+0x2d0 >> zone_foreach() at zone_foreach+0x6c >> uma_reclaim() at uma_reclaim+0x20 >> vm_pageout() at vm_pageout+0x9b8 >> fork_exit() at fork_exit+0x9c >> fork_trampoline() at fork_trampoline+0x8 >> > > Have you asked alc@ about these? > > Marius > > I have now :) Kris From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 23:29:41 2007 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 639CD16A418 for ; Sun, 4 Nov 2007 23:29:41 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id C0E2713C4BB for ; Sun, 4 Nov 2007 23:29:40 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.1/8.14.1/ALCHEMY.FRANKEN.DE) with ESMTP id lA4MkJvC080243; Sun, 4 Nov 2007 23:46:19 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.1/8.14.1/Submit) id lA4MkJ91080242; Sun, 4 Nov 2007 23:46:19 +0100 (CET) (envelope-from marius) Date: Sun, 4 Nov 2007 23:46:18 +0100 From: Marius Strobl To: Kris Kennaway Message-ID: <20071104224618.GD36824@alchemy.franken.de> References: <46FEADFD.8020105@FreeBSD.org> <20071003132944.GA17342@alchemy.franken.de> <200710060222.31023.jhb@freebsd.org> <20071006132620.GF24840@alchemy.franken.de> <472DFC18.3080000@FreeBSD.org> <472E4573.3090708@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <472E4573.3090708@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@FreeBSD.org, John Baldwin Subject: Re: 7.0 broken on e4500 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: Sun, 04 Nov 2007 23:29:41 -0000 On Sun, Nov 04, 2007 at 11:19:31PM +0100, Kris Kennaway wrote: > Kris Kennaway wrote: > >Marius Strobl wrote: > >>On Sat, Oct 06, 2007 at 02:22:30AM -0400, John Baldwin wrote: > >>>On Wednesday 03 October 2007 09:29:44 am Marius Strobl wrote: > >>>>On Sat, Sep 29, 2007 at 09:56:45PM +0200, Kris Kennaway wrote: > >>>>>I get this early during boot with a CVS kernel (updated from last > >>>December): > >>>>>>FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs > >>>>>>panic: tsb_tte_enter: replacing valid kernel mapping > >>>>>>cpuid = 0 > >>>>>>KDB: enter: panic > >>>>>>[thread pid 0 tid 0 ] > >>>>>>Stopped at kdb_enter+0x68: ta %xcc, 1 > >>>>>>db> wh > >>>>>>Tracing pid 0 tid 0 td 0xc0744f80 > >>>>>>panic() at panic+0x204 > >>>>>>tsb_tte_enter() at tsb_tte_enter+0xdc > >>>>>>pmap_enter_locked() at pmap_enter_locked+0x2d0 > >>>>>>pmap_enter() at pmap_enter+0x64 > >>>>>>kmem_malloc() at kmem_malloc+0x6e0 > >>>>>>page_alloc() at page_alloc+0x28 > >>>>>>uma_large_malloc() at uma_large_malloc+0x44 > >>>>>>malloc() at malloc+0x1b0 > >>>>>>sf_buf_init() at sf_buf_init+0xf8 > >>>>>>mi_startup() at mi_startup+0x18c > >>>>>>btext() at btext+0x34 > >>>>Do you by chance load the new kernel manually via the loader > >>>>prompt, with the old kernel being <= 8MB in size and the new > >>>>one > 8MB? > >>>I get this panic on an E220R at work, but my "new" kernel is smaller. > >>> > >> > >>If the actual panic string is "vm_phys_paddr_to_vm_page: paddr > >>is not in any segment" than that's the problem I had in mind when > >>replying to Kris but unfortunately failed to describe the right > >>way around. > >> > >>>>ll /boot/kernel/kernel* /boot/test/kernel* > >>>-r-xr-xr-x 1 root wheel 7821094 Feb 6 2007 /boot/kernel/kernel > >>>-r-xr-xr-x 1 root wheel 13902501 Feb 6 2007 > >>>/boot/kernel/kernel.symbols > >>>-r-xr-xr-x 1 root wheel 4534968 Oct 6 00:20 /boot/test/kernel > >>>-r-xr-xr-x 1 root wheel 10101980 Oct 6 00:20 > >>>/boot/test/kernel.symbols > >>> > >>>The working kernel (~7MB) is the GENERIC kernel, and the "test" kernel > >>>is the stripped down kernel for this machine. In my case I'm > >>>panicing in pmap_remove_tte() called from pmap_enter_locked(). I > >>>added some KTR traces to the pmap code to try and investigate, but > >>>I'm guessing the root problem is that the loader doesn't properly > >>>handle telling OFW about needing to change the mappings when > >>>unloading and then loading a new kernel? > >>> > >>>Hmm, it looks like currently the loader doesn't do any sort of MD > >>>callback > >>>when unloading a file, so the loader isn't going to free up the RAM > >>>it asked for from OFW for the old kernel. > >>> > >> > >>Correct, the immediate problem (which I had a patch for somewhere) > >>is that in case the "old" kernel required more TLB slots to be used > >>than the "new" one one can't use the kernel end in order to determine > >>how many slots are used for the kernel map. As you describe the real > >>problem lies within the loader though. The funny thing is that no > >>arch except sparc64 and sun4v seems to rely on the kernel end > >>provided by the loader. > >>If no idea what's the cause of the problem Kris is seeing though. > >> > >>Marius > >> > >> > > > >FYI one of the e4500's is now booting again but another is still failing > >with the same panic: > > > >FreeBSD 8.0-CURRENT #44: Mon Nov 5 01:52:42 JST 2007 > > root@e4500-2.allbsd.org:/usr/src/sys/sparc64/compile/E4500_2 > >real memory = 9663676416 (9216 MB) > >avail memory = 9433554944 (8996 MB) > >cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu1: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu2: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu3: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu4: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu5: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu6: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu7: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu8: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu9: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs > >panic: tsb_tte_enter: replacing valid kernel mapping > >db> wh > >Tracing pid 0 tid 0 td 0xc056ad30 > >panic() at panic+0x248 > >tsb_tte_enter() at tsb_tte_enter+0xdc > >pmap_enter_locked() at pmap_enter_locked+0x318 > >pmap_enter() at pmap_enter+0x64 > >kmem_malloc() at kmem_malloc+0x644 > >page_alloc() at page_alloc+0x28 > >uma_large_malloc() at uma_large_malloc+0x44 > >malloc() at malloc+0x1a0 > >sf_buf_init() at sf_buf_init+0xe8 > >mi_startup() at mi_startup+0x1e8 > >btext() at btext+0x34 > > > >Kris > > > > Another runtime panic from a u60: > > panic() at panic+0x204 > _mtx_assert() at _mtx_assert+0xac > pmap_page_is_mapped() at pmap_page_is_mapped+0x38 > vm_page_free_toq() at vm_page_free_toq+0x4c > vm_page_free() at vm_page_free+0x10 > uma_small_free() at uma_small_free+0x1c > zone_drain() at zone_drain+0x2d0 > zone_foreach() at zone_foreach+0x6c > uma_reclaim() at uma_reclaim+0x20 > vm_pageout() at vm_pageout+0x9b8 > fork_exit() at fork_exit+0x9c > fork_trampoline() at fork_trampoline+0x8 > Have you asked alc@ about these? Marius From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 4 23:55:57 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3187316A420 for ; Sun, 4 Nov 2007 23:55:57 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from sakima.Ivy.NET (sakima.Ivy.NET [IPv6:2610:1f8:dc:41:220:edff:fe27:e764]) by mx1.freebsd.org (Postfix) with ESMTP id C08FE13C4B7 for ; Sun, 4 Nov 2007 23:55:56 +0000 (UTC) (envelope-from carton@Ivy.NET) Received: from castrovalva.Ivy.NET (castrovalva.Ivy.NET [IPv6:2610:1f8:dc:c0::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sakima.Ivy.NET (Postfix) with ESMTP id A6B95A80E9 for ; Sun, 4 Nov 2007 18:57:44 -0500 (EST) Received: by castrovalva.Ivy.NET (Postfix, from userid 405) id 31CE412FD0E; Sun, 4 Nov 2007 18:55:55 -0500 (EST) To: freebsd-sparc64@freebsd.org References: <200711011822.25884.linimon@lonesome.com> <20071104114811.GA19506@soaustin.net> <472DF0DA.7090401@FreeBSD.org> <20071104203144.GA30608@soaustin.net> From: Miles Nordin MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Sun_Nov__4_18:55:54_2007-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 04 Nov 2007 18:55:54 -0500 In-Reply-To: <20071104203144.GA30608@soaustin.net> (Mark Linimon's message of "Sun, 4 Nov 2007 14:31:44 -0600") Message-ID: User-Agent: T-gnus/6.17.2 (based on No Gnus v0.2) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.4 (alpha--netbsd) MULE/5.0 (SAKAKI) Subject: Re: Doesn't anything work around here? 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: Sun, 04 Nov 2007 23:55:57 -0000 --pgp-sign-Multipart_Sun_Nov__4_18:55:54_2007-1 Content-Type: text/plain; charset=US-ASCII >>>>> "ml" == Mark Linimon writes: ml> And thus, your recommendation is? I wouldn't risk hazarding one. I'm not blaming anyone. It just sucks is all. ml> If you want things fixed, you're going to need to be proactive ml> in identifying sources of breakage and notifying the people ml> that caused them, whether that's via email or send-pr. yes, agreed. but it can be overwhelming to spend one's time compiling things over and over again just to keep security-patched what used to work fine yesterday, especially for someone who is bored with sysadmining and would like a stable platform from which to work on something else. Also I've found that reporting problems is a poor way of getting them fixed. It's much better to fix yourself the one problem you find most bothersome, than to meticulously report ten other problems. In my experience filing problem reports mostly earns you yearly emails, ``I'm thinking of working on your problem, but before I work on this, please rebuild your whole system with our latest CVS and report back whether you're still having the problem.'' This goes on ~forever. For something like a broken web browser, it's _so_ ubiquitously used that I think the few people able to fix the convoluted mess will become interested in fixing it and discover the problem at approximately the same time. ``Firefox doesn't work'' probably already isn't some obscure bug for which we need more testers becuase it keeps slipping through the cracks. The other issue is, the web browser keeps breaking, so if what some user wants is a *stable platform* from which to do other things besides repeatedly recompile FreeBSD, reporting doesn't get you what you want because it's just going to break again. What helps get you what you want is: knowing that the web browser keeps breaking on sparc64. Knowing this, you can avoid running this platform on desktops, which will get you what you want! As a user who doesn't know how, or want to learn how, to fix web browsers (yes, such people *DO* exist and shouldn't have to appologize for existing!), stubbornly continuing to use the platform while blaming yourself for not operating a bunch of constabuild labs and aggressively keeping up with a dozen PR's won't get you closer to what you want. I hope no one feels like I'm discounting his or her contribution, or blaming volunteers for something, even if I don't consistently keep my frustration politely hidden. :) I am allowed to be frustrated, right? That's not wrong, is it? --pgp-sign-Multipart_Sun_Nov__4_18:55:54_2007-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iQCVAwUARy5cConCBbTaW/4dAQJCTAP+JN/ZU7KSIdMS5S/XRJjYx1eaPR6P4qx/ C+us2GY/kEWRXRisdve3HK+po7Ybbtz7a9RfYqfptyqwJNIrx7UPhs35+Z1anf+f 9F6pMGh6XAqx4c3QoCjuAZ9mU3k9DA72hvuVLnKebXo63S4t55w8aeMIpK3WgTCH t5AQWe8SI7E= =Gk4I -----END PGP SIGNATURE----- --pgp-sign-Multipart_Sun_Nov__4_18:55:54_2007-1-- From owner-freebsd-sparc64@FreeBSD.ORG Mon Nov 5 00:33:09 2007 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6024116A46E; Mon, 5 Nov 2007 00:33:09 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB9B13C4AC; Mon, 5 Nov 2007 00:33:09 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 063F62C2B28; Sun, 4 Nov 2007 18:02:01 -0600 (CST) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2aHZv1z0GoNX; Sun, 4 Nov 2007 18:01:53 -0600 (CST) Received: from [216.63.78.18] (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 2DD9B2C2ADF; Sun, 4 Nov 2007 18:01:53 -0600 (CST) Message-ID: <472E5D70.3020009@cs.rice.edu> Date: Sun, 04 Nov 2007 18:01:52 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070805 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <46FEADFD.8020105@FreeBSD.org> <20071003132944.GA17342@alchemy.franken.de> <200710060222.31023.jhb@freebsd.org> <20071006132620.GF24840@alchemy.franken.de> <472DFC18.3080000@FreeBSD.org> <472E4573.3090708@FreeBSD.org> <20071104224618.GD36824@alchemy.franken.de> <472E54D0.8070807@FreeBSD.org> In-Reply-To: <472E54D0.8070807@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@FreeBSD.org, freebsd-sparc64@FreeBSD.org, John Baldwin , Marius Strobl Subject: Re: 7.0 broken on e4500 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, 05 Nov 2007 00:33:09 -0000 Kris Kennaway wrote: > Marius Strobl wrote: > >> On Sun, Nov 04, 2007 at 11:19:31PM +0100, Kris Kennaway wrote: >> >>> >>>> >>> Another runtime panic from a u60: >>> >>> panic() at panic+0x204 >>> _mtx_assert() at _mtx_assert+0xac >>> pmap_page_is_mapped() at pmap_page_is_mapped+0x38 >>> vm_page_free_toq() at vm_page_free_toq+0x4c >>> vm_page_free() at vm_page_free+0x10 >>> uma_small_free() at uma_small_free+0x1c >>> zone_drain() at zone_drain+0x2d0 >>> zone_foreach() at zone_foreach+0x6c >>> uma_reclaim() at uma_reclaim+0x20 >>> vm_pageout() at vm_pageout+0x9b8 >>> fork_exit() at fork_exit+0x9c >>> fork_trampoline() at fork_trampoline+0x8 >>> >> >> Have you asked alc@ about these? >> >> Marius >> >> > > I have now :) > Let's deal with the latter case first. This case was supposed to be fixed by this change: alc 2007-10-07 18:03:04 UTC FreeBSD src repository Modified files: sys/sparc64/sparc64 pmap.c sys/vm vm_page.c Log: Correct a lock assertion failure in sparc64's pmap_page_is_mapped() that is a consequence of sparc64/sparc64/vm_machdep.c revision 1.76. It occurs when uma_small_free() frees a page. The solution has two parts: (1) Mark pages allocated with VM_ALLOC_NOOBJ as PG_UNMANAGED. (2) Defer the lock assertion in pmap_page_is_mapped() until after PG_UNMANAGED is tested. This is safe because both PG_UNMANAGED and PG_FICTITIOUS are immutable flags, i.e., they do not change state between the time that a page is allocated and freed. Approved by: re (kensmith) PR: 116794 Revision Changes Path 1.166 +1 -1 src/sys/sparc64/sparc64/pmap.c 1.356 +1 -1 src/sys/vm/vm_page.c Do you have this change? Alan From owner-freebsd-sparc64@FreeBSD.ORG Mon Nov 5 02:51:06 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6699116A417; Mon, 5 Nov 2007 02:51:06 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 4C49513C4B6; Mon, 5 Nov 2007 02:51:06 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id C60858C0B8; Sun, 4 Nov 2007 20:50:34 -0600 (CST) Date: Sun, 4 Nov 2007 20:50:34 -0600 To: Kris Kennaway Message-ID: <20071105025034.GB31465@soaustin.net> References: <200711011822.25884.linimon@lonesome.com> <472B39A8.3070708@alaska.net> <472DAFBE.9070603@FreeBSD.org> <472E4B8D.2020902@alaska.net> <472E547E.8020104@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <472E547E.8020104@FreeBSD.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) Cc: Mark Linimon , freebsd-sparc64@freebsd.org Subject: Re: hardware and package builds 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, 05 Nov 2007 02:51:06 -0000 On Mon, Nov 05, 2007 at 12:23:42AM +0100, Kris Kennaway wrote: > There is an article in the website documentation that gives some > overview of how these scripts are used. Mark also has private notes > about the care and feeding of the build system, but I don't know if > these are ready for sharing. I've pushed everything that I have learned up into the portbuild article. (OK, I'm a couple of weeks behind.) mcl From owner-freebsd-sparc64@FreeBSD.ORG Mon Nov 5 03:14:24 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A27316A417 for ; Mon, 5 Nov 2007 03:14:24 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 3090313C48D for ; Mon, 5 Nov 2007 03:14:24 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id EA22A8C0B6; Sun, 4 Nov 2007 20:47:11 -0600 (CST) Date: Sun, 4 Nov 2007 20:47:11 -0600 To: Miles Nordin Message-ID: <20071105024711.GA31465@soaustin.net> References: <200711011822.25884.linimon@lonesome.com> <20071104114811.GA19506@soaustin.net> <472DF0DA.7090401@FreeBSD.org> <20071104203144.GA30608@soaustin.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) Cc: freebsd-sparc64@freebsd.org Subject: Re: Doesn't anything work around here? 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, 05 Nov 2007 03:14:24 -0000 On Sun, Nov 04, 2007 at 06:55:54PM -0500, Miles Nordin wrote: > Also I've found that reporting problems is a poor way of getting them > fixed. Not reporting them is even worse :-) > For something like a broken web browser, it's _so_ ubiquitously used Assuming a large number of people using sparc64 on the desktop ... yes. I'm skeptical of that. > I am allowed to be frustrated, right? Fair enough, but I don't see a problem fix in sight. mcl From owner-freebsd-sparc64@FreeBSD.ORG Mon Nov 5 11:07:06 2007 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 469F516A47E for ; Mon, 5 Nov 2007 11:07:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1EFD113C4B0 for ; Mon, 5 Nov 2007 11:07:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id lA5B75mP026444 for ; Mon, 5 Nov 2007 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id lA5B759Y026440 for freebsd-sparc64@FreeBSD.org; Mon, 5 Nov 2007 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Nov 2007 11:07:05 GMT Message-Id: <200711051107.lA5B759Y026440@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org 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, 05 Nov 2007 11:07:06 -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/95297 sparc64 vt100 term does not work in install o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/105607 sparc64 [modules] modules on sparc64 don't work with >= 4GB o sparc/106251 sparc64 [libmalloc] malloc fails > for large allocations s sparc/107087 sparc64 system is hinged during boot from CD o sparc/107947 sparc64 [libthr] mysqld periodically core dumps (signal 4) wit o sparc/109908 sparc64 apache22 mod_perl issue on sparc64 o sparc/113556 sparc64 panic: trap: memory address not aligned; Rebooting... o sparc/116315 sparc64 /sbin permission 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/72998 sparc64 [kernel] [patch] set_mcontext() change syscalls parame 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(8) reports 14 digit time on sparc64 o sparc/108757 sparc64 [rtc] can't boot if rtc stuffed, no means of recovery o sparc/114349 sparc64 When executing snmpd it immediately stops with a segme 8 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Nov 5 18:00:40 2007 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41C1516A417 for ; Mon, 5 Nov 2007 18:00:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from gnome.kiev.sovam.com (gnome.kiev.sovam.com [212.109.32.24]) by mx1.freebsd.org (Postfix) with ESMTP id DB28913C481 for ; Mon, 5 Nov 2007 18:00:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com ([62.64.120.197]) by gnome.kiev.sovam.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ip33g-0007IK-TB; Mon, 05 Nov 2007 16:36:08 +0200 Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ip33d-000O6A-2Q; Mon, 05 Nov 2007 16:36:07 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id lA5Ea3vQ041481; Mon, 5 Nov 2007 16:36:03 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id lA5Ea3kU041480; Mon, 5 Nov 2007 16:36:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Nov 2007 16:36:03 +0200 From: Kostik Belousov To: Kris Kennaway Message-ID: <20071105143603.GS37471@deviant.kiev.zoral.com.ua> References: <472DF090.8070904@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Tdr039sUWCyRuLRO" Content-Disposition: inline In-Reply-To: <472DF090.8070904@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 1118cf21f7425d415ed61e91afc5cb63 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1735 [Nov 04 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: kib@freebsd.org, sparc64@freebsd.org Subject: Re: trap from DEBUG_LOCKS 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, 05 Nov 2007 18:00:40 -0000 --Tdr039sUWCyRuLRO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 04, 2007 at 05:17:20PM +0100, Kris Kennaway wrote: > The insta-panic at boot on sparc64 with RELENG_7 seems to be fixed, but= =20 > at the point when it mounts root I get the following panic when=20 > DEBUG_LOCKS is enabled: >=20 > panic: trap: memory address not aligned > cpuid =3D 9 > KDB: enter: panic > [thread pid 1 tid 100006 ] > Stopped at kdb_enter+0x68: ta %xcc, 1 > db> wh > Tracing pid 1 tid 100006 td 0xfffff800020709c0 > panic() at panic+0x204 > trap() at trap+0x56c > -- memory address not aligned sfar=3D0xe2f47c27 sfsr=3D0x40029 %o7=3D0xc0= 3cd524 -- > stack_save() at stack_save+0x18 > _lockmgr() at _lockmgr+0x4c > vfs_busy() at vfs_busy+0x1d4 > vfs_mount_alloc() at vfs_mount_alloc+0x58 > vfs_mountroot() at vfs_mountroot+0x2e4 > start_init() at start_init+0x58 > fork_exit() at fork_exit+0x9c > fork_trampoline() at fork_trampoline+0x8 Could you, please, show me the content of the registers and disassembly for the stack_save() ? (Last time I looked into sparc64 assembly, was 3 years ago). --Tdr039sUWCyRuLRO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHLypRC3+MBN1Mb4gRArj9AKCaHuQc9sP+1u7OYtnD6H2zlfYIHwCfT1Mv pd29tfx2/1nlIim9jpAwLXU= =joOl -----END PGP SIGNATURE----- --Tdr039sUWCyRuLRO-- From owner-freebsd-sparc64@FreeBSD.ORG Mon Nov 5 18:59:43 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3185016A41A for ; Mon, 5 Nov 2007 18:59:43 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id D8AC413C4A8 for ; Mon, 5 Nov 2007 18:59:42 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0JR100AKDOHASM60@osl1smout1.broadpark.no> for freebsd-sparc64@freebsd.org; Mon, 05 Nov 2007 18:55:58 +0100 (CET) Received: from kg-work.kg4.no ([80.202.172.249]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0JR1006LNOH9XE01@osl1sminn1.broadpark.no> for freebsd-sparc64@freebsd.org; Mon, 05 Nov 2007 18:55:58 +0100 (CET) Date: Mon, 05 Nov 2007 18:55:57 +0100 From: Torfinn Ingolfsen To: freebsd-sparc64@freebsd.org Message-id: <20071105185557.a8d79a37.torfinn.ingolfsen@broadpark.no> In-reply-to: <20071105024711.GA31465@soaustin.net> References: <200711011822.25884.linimon@lonesome.com> <20071104114811.GA19506@soaustin.net> <472DF0DA.7090401@FreeBSD.org> <20071104203144.GA30608@soaustin.net> <20071105024711.GA31465@soaustin.net> X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd6.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: Doesn't anything work around here? 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, 05 Nov 2007 18:59:43 -0000 On Sun, 04 Nov 2007 20:47:11 -0600 linimon@lonesome.com (Mark Linimon) wrote: > Assuming a large number of people using sparc64 on the desktop ... For the sake of interest; is there a cheap, small and (preferably) silent sparc64 machine that could be used as a desktop available? My old Ultra 1E Creator3D doesn't quite qualify... -- Regards, Torfinn Ingolfsen From owner-freebsd-sparc64@FreeBSD.ORG Mon Nov 5 20:19:35 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE8AD16A41B for ; Mon, 5 Nov 2007 20:19:35 +0000 (UTC) (envelope-from mark@foster.cc) Received: from rwcrmhc15.comcast.net (rwcrmhc15.comcast.net [204.127.192.85]) by mx1.freebsd.org (Postfix) with ESMTP id A74C213C481 for ; Mon, 5 Nov 2007 20:19:35 +0000 (UTC) (envelope-from mark@foster.cc) Received: from fosgate.dyndns.org ([24.17.77.253]) by comcast.net (rwcrmhc15) with ESMTP id <20071105200417m15009ucthe>; Mon, 5 Nov 2007 20:04:17 +0000 Received: from localhost (localhost [127.0.0.1]) by fosgate.dyndns.org (Postfix) with ESMTP id AAA8B39825 for ; Mon, 5 Nov 2007 12:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at foster.cc Received: from fosgate.dyndns.org ([127.0.0.1]) by localhost (sonar.foster.dmz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCLTNgslXYpL for ; Mon, 5 Nov 2007 12:00:31 -0800 (PST) Received: from [10.1.253.127] (fis-gw1.portseattle.org [198.134.96.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by fosgate.dyndns.org (Postfix) with ESMTP id 7CC2D3982B for ; Mon, 5 Nov 2007 12:00:31 -0800 (PST) Message-ID: <472F7739.2070201@foster.cc> Date: Mon, 05 Nov 2007 12:04:09 -0800 From: "Mark D. Foster" User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 CC: freebsd-sparc64@freebsd.org References: <200711011822.25884.linimon@lonesome.com> <20071104114811.GA19506@soaustin.net> <472DF0DA.7090401@FreeBSD.org> <20071104203144.GA30608@soaustin.net> <20071105024711.GA31465@soaustin.net> <20071105185557.a8d79a37.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20071105185557.a8d79a37.torfinn.ingolfsen@broadpark.no> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Doesn't anything work around here? 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, 05 Nov 2007 20:19:35 -0000 Torfinn Ingolfsen wrote: > For the sake of interest; is there a cheap, small and (preferably) > silent sparc64 machine that could be used as a desktop available? > My old Ultra 1E Creator3D doesn't quite qualify... > Dunno, but soon Qemu will (could) have decent support for sparc64 emulation. Then access to physical hardware would be moot ...perhaps more so for ports. http://fabrice.bellard.free.fr/qemu/status.html -- Said one park ranger, 'There is considerable overlap between the intelligence of the smartest bears and the dumbest tourists.' Mark D. Foster, CISSP http://mark.foster.cc/ From owner-freebsd-sparc64@FreeBSD.ORG Mon Nov 5 23:04:55 2007 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C3D716A46B; Mon, 5 Nov 2007 23:04:55 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF1513C4AC; Mon, 5 Nov 2007 23:04:48 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <472FA18E.2020402@FreeBSD.org> Date: Tue, 06 Nov 2007 00:04:46 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kostik Belousov References: <472DF090.8070904@FreeBSD.org> <20071105143603.GS37471@deviant.kiev.zoral.com.ua> In-Reply-To: <20071105143603.GS37471@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kib@freebsd.org, sparc64@freebsd.org Subject: Re: trap from DEBUG_LOCKS 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, 05 Nov 2007 23:04:55 -0000 Kostik Belousov wrote: > On Sun, Nov 04, 2007 at 05:17:20PM +0100, Kris Kennaway wrote: >> The insta-panic at boot on sparc64 with RELENG_7 seems to be fixed, but >> at the point when it mounts root I get the following panic when >> DEBUG_LOCKS is enabled: >> >> panic: trap: memory address not aligned >> cpuid = 9 >> KDB: enter: panic >> [thread pid 1 tid 100006 ] >> Stopped at kdb_enter+0x68: ta %xcc, 1 >> db> wh >> Tracing pid 1 tid 100006 td 0xfffff800020709c0 >> panic() at panic+0x204 >> trap() at trap+0x56c >> -- memory address not aligned sfar=0xe2f47c27 sfsr=0x40029 %o7=0xc03cd524 -- >> stack_save() at stack_save+0x18 >> _lockmgr() at _lockmgr+0x4c >> vfs_busy() at vfs_busy+0x1d4 >> vfs_mount_alloc() at vfs_mount_alloc+0x58 >> vfs_mountroot() at vfs_mountroot+0x2e4 >> start_init() at start_init+0x58 >> fork_exit() at fork_exit+0x9c >> fork_trampoline() at fork_trampoline+0x8 > > Could you, please, show me the content of the registers and disassembly > for the stack_save() ? (Last time I looked into sparc64 assembly, was 3 > years ago). db> wh Tracing pid 1 tid 100006 td 0xfffff800020709c0 panic() at panic+0x204 trap() at trap+0x56c -- memory address not aligned sfar=0xe2f47c27 sfsr=0x40029 %o7=0xc03cd584 -- stack_save() at stack_save+0x18 _lockmgr() at _lockmgr+0x4c vfs_busy() at vfs_busy+0x1d4 vfs_mount_alloc() at vfs_mount_alloc+0x58 vfs_mountroot() at vfs_mountroot+0x2e4 start_init() at start_init+0x58 fork_exit() at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 stack_save: save %sp, -0xc0, %sp stack_save+0x4: call stack_zero stack_save+0x8: or %g0, %i0, %o0 stack_save+0xc: flushw stack_save+0x10: ldx [%fp + 0x86f], %g1 stack_save+0x14: add %g1, 0xffe, %l0 stack_save+0x18: ldx [%l0 + 0x78], %o1 stack_save+0x1c: sethi %hi(0xbffffc00), %g1 stack_save+0x20: or %g1, 0x3ff, %g1 stack_save+0x24: subcc %o1, %g1, %g0 stack_save+0x28: bleu,pn stack_save+0x50 stack_save+0x2c: sethi %hi(0x0), %g1 stack_save+0x30: or %g1, 0x0, %g1 stack_save+0x34: sllx %g1, 32, %g1 stack_save+0x38: sethi %hi(0xc0616c00), %g2 stack_save+0x3c: add %g1, %g2, %g1 stack_save+0x40: ldx [%g1 + 0x370], %g1 stack_save+0x44: subcc %o1, %g1, %g0 stack_save+0x48: bleu,pt stack_save+0x78 stack_save+0x4c: sethi %hi(0x0), %g1 db> show reg g0 0 g1 0 g2 0xc0572c00 dumppcb+0x500 g3 0xca8ff g4 0xa pcpup+0x3 g5 0xfffff8000140fff8 g6 0xe2f47980 g7 0xe22dfa90 i0 0x12 pcpup+0xb i1 0xc04df530 i2 0xe2f46d78 i3 0xa pcpup+0x3 i4 0xe2f46e50 i5 0 i6 0xe2f46501 i7 0xc0213a40 kdb_enter+0x60 tnpc 0xc0213a4c kdb_enter+0x6c tpc 0xc0213a48 kdb_enter+0x68 tstate 0x4415001601 kdb_enter+0x68: ta %xcc, 1 (It looks like it is not dumping all registers) Kris From owner-freebsd-sparc64@FreeBSD.ORG Tue Nov 6 06:58:01 2007 Return-Path: Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCC4F16A419 for ; Tue, 6 Nov 2007 06:58:01 +0000 (UTC) (envelope-from info-grants@SoftHome.net) Received: from trinity.rocler.com (trinity.rocler.com [216.137.96.58]) by mx1.freebsd.org (Postfix) with ESMTP id 78A4B13C480 for ; Tue, 6 Nov 2007 06:58:01 +0000 (UTC) (envelope-from info-grants@SoftHome.net) Received: from hfhjfhjfjf-7456hh4g (dsl-dyn-107-107.rocler.com [216.137.107.107]) by trinity.rocler.com (8.14.1/8.14.1) with ESMTP id lA63xK9S026051 for ; Mon, 5 Nov 2007 22:59:20 -0500 From: "Canadian subsidy directory 2007" To: freebsd-sparc@freebsd.org Date: Mon, 5 Nov 2007 22:59:55 -0500 MIME-Version: 1.0 Message-ID: <119427540875f4dd5937cbb4642537093f665e4f30@SoftHome.net> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.63 on 216.137.96.58 Cc: Subject: =?iso-8859-1?q?Press_release_/_Communiqu=E9?= 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, 06 Nov 2007 06:58:01 -0000 (Message en francais ci-dessous) PRESS RELEASE C A N A D I A N S U B S I D Y D I R E C T O R Y Legal Deposit-National Library The Canadian Subsidy Directory 2007 is now available, newly revised it is the most complete and affordable reference for anyone looking for financing. It is the perfect tool for new and existing businesses, individuals, foundations and associations. This Publication contains more than 3200 direct and indirect financial subsidies, grants and loans offered by government departments and agencies, foundations, associations and organizations. In this new 2007 edition all programs are well described. The C a n a d i a n S u b s i d y D i r e c t o r y is the most comprehensive tool to start up a business, improve existent activities, set up a business plan, or obtain assistance from experts in fields such as: Industry, transport, agriculture, communications, municipal infrastructure, education, import-export, labour, construction and renovation, the service sector, hi-tech industries, research and development, joint ventures, arts, cinema, theatre, music and recording industry, the self employed, contests, and new talents. Assistance from and for foundations and associations, guidance to prepare a business plan, market surveys, computers, and much more! The Canadian Subsidy Directory is sold $ 69.95 (CD-ROM), $ 149.95 (Printed 430 pages) to obtain a copy please call toll free **1-866-322-3376** *********************************************** **FRANCAIS** COMMUNIQUÉ DE PRESSE Les Publications Canadiennes offrent au public une édition révisée de l' A N N U A I R E D E S S U B V E N T I O N S A U Q U É B E C contenant plus de 1900 programmes d'aides et de subventions provenant des divers paliers gouvernementaux et organismes. L' A N N U A I R E D E S S U B V E N T I O N S A U Q U É B E C est l'outil idéal soit pour démarrer son entreprise, améliorer une entreprise existante, mettre sur pied son plan d'affaires ou obtenir l'aide de conseillers experts dans le domaine des affaires: Démarrage d'entreprises, études, recherches, arts, agriculture, import export, main d'oeuvre, cinéma, prêts, promotion, bourses, théatre, transports, communications, mise sur pied et développement d'entreprises, construction et rénovation, aérospatial, concours, nouveaux talents, aide aux associations, organismes et fondations, informatique, musique, industrie du disque, plans d'affaires, études de marchés, infrastructures, aide aux travailleurs autonomes et plus encore ! Cd-rom(format .pdf).............$ 69.95 Imprimé(Cd-inclus) .............$ 149.95 Informations.....................ligne sans frais **1-866-322-3376 unsuscribe requests: use delete2007@mailcan.com From owner-freebsd-sparc64@FreeBSD.ORG Tue Nov 6 07:38:43 2007 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D746316A421; Tue, 6 Nov 2007 07:38:43 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 7E72C13C48A; Tue, 6 Nov 2007 07:38:43 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 5BD982C2C4A; Tue, 6 Nov 2007 01:38:33 -0600 (CST) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KxjgJH7ZfjNL; Tue, 6 Nov 2007 01:38:25 -0600 (CST) Received: from [216.63.78.18] (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 105AA2C2C47; Tue, 6 Nov 2007 01:38:18 -0600 (CST) Message-ID: <473019E8.3070203@cs.rice.edu> Date: Tue, 06 Nov 2007 01:38:16 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070805 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <46FEADFD.8020105@FreeBSD.org> <20071003132944.GA17342@alchemy.franken.de> <200710060222.31023.jhb@freebsd.org> <20071006132620.GF24840@alchemy.franken.de> <472DFC18.3080000@FreeBSD.org> <472E4573.3090708@FreeBSD.org> <20071104224618.GD36824@alchemy.franken.de> <472E54D0.8070807@FreeBSD.org> In-Reply-To: <472E54D0.8070807@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@FreeBSD.org, freebsd-sparc64@FreeBSD.org, John Baldwin , Marius Strobl Subject: Re: 7.0 broken on e4500 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, 06 Nov 2007 07:38:44 -0000 Kris Kennaway wrote: > Marius Strobl wrote: > >> On Sun, Nov 04, 2007 at 11:19:31PM +0100, Kris Kennaway wrote: >> >>> Kris Kennaway wrote: >>> >>>> Marius Strobl wrote: >>>> >>>>> On Sat, Oct 06, 2007 at 02:22:30AM -0400, John Baldwin wrote: >>>>> >>>>>> On Wednesday 03 October 2007 09:29:44 am Marius Strobl wrote: >>>>>> >>>>>>> On Sat, Sep 29, 2007 at 09:56:45PM +0200, Kris Kennaway wrote: >>>>>>> >>>>>>>> I get this early during boot with a CVS kernel (updated from last >>>>>>> >>>>>> December): >>>>>> >>>>>>>>> FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs >>>>>>>>> panic: tsb_tte_enter: replacing valid kernel mapping >>>>>>>>> cpuid = 0 >>>>>>>>> KDB: enter: panic >>>>>>>>> [thread pid 0 tid 0 ] >>>>>>>>> Stopped at kdb_enter+0x68: ta %xcc, 1 >>>>>>>>> db> wh >>>>>>>>> Tracing pid 0 tid 0 td 0xc0744f80 >>>>>>>>> panic() at panic+0x204 >>>>>>>>> tsb_tte_enter() at tsb_tte_enter+0xdc >>>>>>>>> pmap_enter_locked() at pmap_enter_locked+0x2d0 >>>>>>>>> pmap_enter() at pmap_enter+0x64 >>>>>>>>> kmem_malloc() at kmem_malloc+0x6e0 >>>>>>>>> page_alloc() at page_alloc+0x28 >>>>>>>>> uma_large_malloc() at uma_large_malloc+0x44 >>>>>>>>> malloc() at malloc+0x1b0 >>>>>>>>> sf_buf_init() at sf_buf_init+0xf8 >>>>>>>>> mi_startup() at mi_startup+0x18c >>>>>>>>> btext() at btext+0x34 >>>>>>>> >>>>>>> Do you by chance load the new kernel manually via the loader >>>>>>> prompt, with the old kernel being <= 8MB in size and the new >>>>>>> one > 8MB? >>>>>> >>>>>> I get this panic on an E220R at work, but my "new" kernel is >>>>>> smaller. >>>>>> >>>>> If the actual panic string is "vm_phys_paddr_to_vm_page: paddr >>>>> is not in any segment" than that's the problem I had in mind when >>>>> replying to Kris but unfortunately failed to describe the right >>>>> way around. >>>>> >>>>>>> ll /boot/kernel/kernel* /boot/test/kernel* >>>>>> >>>>>> -r-xr-xr-x 1 root wheel 7821094 Feb 6 2007 /boot/kernel/kernel >>>>>> -r-xr-xr-x 1 root wheel 13902501 Feb 6 2007 >>>>>> /boot/kernel/kernel.symbols >>>>>> -r-xr-xr-x 1 root wheel 4534968 Oct 6 00:20 /boot/test/kernel >>>>>> -r-xr-xr-x 1 root wheel 10101980 Oct 6 00:20 >>>>>> /boot/test/kernel.symbols >>>>>> >>>>>> The working kernel (~7MB) is the GENERIC kernel, and the "test" >>>>>> kernel >>>>>> is the stripped down kernel for this machine. In my case I'm >>>>>> panicing in pmap_remove_tte() called from pmap_enter_locked(). I >>>>>> added some KTR traces to the pmap code to try and investigate, >>>>>> but I'm guessing the root problem is that the loader doesn't >>>>>> properly handle telling OFW about needing to change the mappings >>>>>> when unloading and then loading a new kernel? >>>>>> >>>>>> Hmm, it looks like currently the loader doesn't do any sort of MD >>>>>> callback >>>>>> when unloading a file, so the loader isn't going to free up the >>>>>> RAM it asked for from OFW for the old kernel. >>>>>> >>>>> Correct, the immediate problem (which I had a patch for somewhere) >>>>> is that in case the "old" kernel required more TLB slots to be used >>>>> than the "new" one one can't use the kernel end in order to determine >>>>> how many slots are used for the kernel map. As you describe the real >>>>> problem lies within the loader though. The funny thing is that no >>>>> arch except sparc64 and sun4v seems to rely on the kernel end >>>>> provided by the loader. >>>>> If no idea what's the cause of the problem Kris is seeing though. >>>>> >>>>> Marius >>>>> >>>>> >>>> FYI one of the e4500's is now booting again but another is still >>>> failing with the same panic: >>>> >>>> FreeBSD 8.0-CURRENT #44: Mon Nov 5 01:52:42 JST 2007 >>>> root@e4500-2.allbsd.org:/usr/src/sys/sparc64/compile/E4500_2 >>>> real memory = 9663676416 (9216 MB) >>>> avail memory = 9433554944 (8996 MB) >>>> cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>> cpu1: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>> cpu2: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>> cpu3: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>> cpu4: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>> cpu5: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>> cpu6: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>> cpu7: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>> cpu8: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>> cpu9: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>> FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs >>>> panic: tsb_tte_enter: replacing valid kernel mapping >>>> db> wh >>>> Tracing pid 0 tid 0 td 0xc056ad30 >>>> panic() at panic+0x248 >>>> tsb_tte_enter() at tsb_tte_enter+0xdc >>>> pmap_enter_locked() at pmap_enter_locked+0x318 >>>> pmap_enter() at pmap_enter+0x64 >>>> kmem_malloc() at kmem_malloc+0x644 >>>> page_alloc() at page_alloc+0x28 >>>> uma_large_malloc() at uma_large_malloc+0x44 >>>> malloc() at malloc+0x1a0 >>>> sf_buf_init() at sf_buf_init+0xe8 >>>> mi_startup() at mi_startup+0x1e8 >>>> btext() at btext+0x34 >>>> Can anyone tell me more about the "vm_phys_paddr_to_vm_page: paddr is not in any segment" panic? Alan From owner-freebsd-sparc64@FreeBSD.ORG Tue Nov 6 08:28:34 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BD0616A417 for ; Tue, 6 Nov 2007 08:28:34 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 6A00313C491 for ; Tue, 6 Nov 2007 08:28:34 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from bighuge.lonesome.com (cpe-66-68-146-180.austin.res.rr.com [66.68.146.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.soaustin.net (Postfix) with ESMTP id 529978C0AB; Tue, 6 Nov 2007 02:28:26 -0600 (CST) From: Mark Linimon Organization: Lonesome Dove Computing Services To: dan@freebsd-host.net Date: Mon, 5 Nov 2007 22:25:07 -0500 User-Agent: KMail/1.9.7 References: <200711011822.25884.linimon@lonesome.com> <472B35E7.7020801@freebsd-host.net> In-Reply-To: <472B35E7.7020801@freebsd-host.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711052125.07569.linimon@lonesome.com> Cc: freebsd-sparc64@freebsd.org Subject: Re: Doesn't anything work around here? 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, 06 Nov 2007 08:28:34 -0000 On Friday 02 November 2007, Daniel Austin MBCS wrote: > I'm more than happy to test out ports on sparc64. I have a few > sparc64 8.0-current machines here. FWIW, if I have not already mentioned in this thread or this list, I have some portsmon pages that will help you figure out the state of ports on specific build environments. The germane ones are: http://portsmon.freebsd.org/chartsandgraphs/package_failures_list.sparc64-6.html http://portsmon.freebsd.org/chartsandgraphs/package_failures_list.sparc64-7.html These are from the last full runs, so the -6 one is one month old and the -7 one is two months old. The latest -7 run is nearly finished. There is no -8 run yet. Graphical representations of the above are at: http://portsmon.freebsd.org/chartsandgraphs/package_status.sparc64-6.html http://portsmon.freebsd.org/chartsandgraphs/package_status.sparc64-7.html and a comparison across all the buildenvs is at: http://portsmon.freebsd.org/chartsandgraphs/package_comparison.html All the above include packages that aren't built for one reason or another. On pointyhat, the "latest failures" list of error logs (only) are at: http://pointyhat.freebsd.org/errorlogs/sparc64-6-failure.html http://pointyhat.freebsd.org/errorlogs/sparc64-7-failure.html and the "latest run" summaries are at: http://pointyhat.freebsd.org/errorlogs/sparc64-6-full/ http://pointyhat.freebsd.org/errorlogs/sparc64-6-latest/ http://pointyhat.freebsd.org/errorlogs/sparc64-7-full/ http://pointyhat.freebsd.org/errorlogs/sparc64-7-latest/ This should tell all you want to know, and much more, about the state of ports and packages on sparc64. mcl From owner-freebsd-sparc64@FreeBSD.ORG Tue Nov 6 08:50:30 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0218D16A417; Tue, 6 Nov 2007 08:50:30 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id CA09213C4A6; Tue, 6 Nov 2007 08:50:29 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from bighuge.lonesome.com (cpe-66-68-146-180.austin.res.rr.com [66.68.146.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.soaustin.net (Postfix) with ESMTP id 2C7188C0AE; Tue, 6 Nov 2007 02:50:18 -0600 (CST) From: Mark Linimon Organization: Lonesome Dove Computing Services To: Royce Williams Date: Mon, 5 Nov 2007 22:46:59 -0500 User-Agent: KMail/1.9.7 References: <472DAFBE.9070603@FreeBSD.org> <472E4B8D.2020902@alaska.net> In-Reply-To: <472E4B8D.2020902@alaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711052146.59344.linimon@lonesome.com> Cc: freebsd-sparc64@freebsd.org Subject: Re: hardware and package builds (was: Re: Doesn't anything work around here?) 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, 06 Nov 2007 08:50:30 -0000 > Load/use: How much daily/hourly load would the system see? In case it wasn't mentioned above, the ports builds tend to keep disk drives 100% busy. We've tested many drives to destruction. mcl From owner-freebsd-sparc64@FreeBSD.ORG Tue Nov 6 13:44:40 2007 Return-Path: Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A168D16A418 for ; Tue, 6 Nov 2007 13:44:40 +0000 (UTC) (envelope-from member@ebay.com) Received: from mxphxpool69.ebay.com (mxphxpool69.ebay.com [66.211.161.69]) by mx1.freebsd.org (Postfix) with ESMTP id 574FF13C491 for ; Tue, 6 Nov 2007 13:44:40 +0000 (UTC) (envelope-from member@ebay.com) Received: from mxpool20.ebay.com (HELO mx38.sjc.ebay.com) ([66.135.197.26]) by mxphxpool69.ebay.com with ESMTP; 06 Nov 2007 05:44:07 -0800 Received: from sj-v3conta32 (sj-v3conta32.sjc.ebay.com [10.11.88.125]) by mx38.sjc.ebay.com (8.13.5/8.13.5) with ESMTP id lA6DhqCK017169 for ; Tue, 6 Nov 2007 06:43:52 -0700 DomainKey-Signature: a=rsa-sha1; s=dksm28; d=ebay.com; c=nofws; q=dns; h=from:reply-to:to:subject:x-ebay-mailtracker: x-ebay-mailversiontracker:mime-version:content-type; b=FSPBjzdTIuEPFpbrWsvPRVg8omJCBe+aeRS3TdWXOvFNuntPr8AtjSGxfJr3QPKJD 1j9wWZ0yGBHJAPS4PDaPQ== Date: Tue, 6 Nov 2007 06:43:52 -0700 Message-Id: <200711061343.lA6DhqCK017169@mx38.sjc.ebay.com> From: eBay To: freebsd-sparc@freebsd.org X-eBay-MailTracker: 11030.537.0.774 X-eBay-MailVersionTracker: 537.5593657 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: uzhadzuna thought you might like this item on eBay X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: member@ebay.com List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2007 13:44:40 -0000 ----------------------------------------------------------------- An eBay member wants to show you this item ----------------------------------------------------------------- Dear friend, we are one of the largest Chinese electronic exporting =20 wholesalers ,who can support you the best service and high quality products= =20 with competitive price we hope that you can take out your busy time to=20 have a look at www.oncemore2688.com ,and you will find many electronic=20 products.we will send the goods in a fast speed and safety way. Looking=20 forward to doing long term business ship with you.=20 ----- Website:=20 www.oncemore2688.com ----- ----- Msn/Email:=20 family-shoppings@hotmail.com ----- -----=20 http://www.oncemore2688.com/productlist.asp?sid=3D10400000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Show me http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&&item=3D150167195522 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Item name: Brand New Dell Notebook Xps M2010 Laptop 120g Current price: PHP 21,058.00=20 End time: Oct-01-07 06:31:57 PDT ----------------------------------------------------------------- Learn how you can protect yourself from spoof (fake) emails at:=20 http://pages.ebay.com/education/spooftutorial/index.html This email sent through the eBay platform from a sender who thinks you are= =20 likely to be interested in this information. eBay takes no liability for=20 sending this email or its content. You can report this message at=20 http://pages.ebay.com/help/policies/rfe-spam-ov.html as unsolicited=20 (spam/spoof) email. Copyright =A9 2007 eBay Inc. All Rights Reserved. Designated trademarks and brands are the property of their respective=20 owners. eBay and the eBay logo are trademarks of eBay Inc. eBay Inc. is located at 2145 Hamilton Avenue, San Jose, CA 95125. From owner-freebsd-sparc64@FreeBSD.ORG Wed Nov 7 16:54:40 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3555B16A419 for ; Wed, 7 Nov 2007 16:54:40 +0000 (UTC) (envelope-from m_roethlein@web.de) Received: from fmmailgate09.web.de (fmmailgate09.web.de [217.72.192.184]) by mx1.freebsd.org (Postfix) with ESMTP id C7FEE13C4B0 for ; Wed, 7 Nov 2007 16:54:39 +0000 (UTC) (envelope-from m_roethlein@web.de) Received: from web.de by fmmailgate09.web.de (Postfix) with SMTP id 02E7614CDF69 for ; Wed, 7 Nov 2007 17:30:18 +0100 (CET) Received: from [84.147.63.9] by freemailng1705.web.de with HTTP; Wed, 07 Nov 2007 17:30:17 +0100 Date: Wed, 07 Nov 2007 17:30:17 +0100 Message-Id: <1859732180@web.de> MIME-Version: 1.0 From: Martin Roethlein To: freebsd-sparc64@freebsd.org Precedence: fm-user Organization: http://freemail.web.de/ X-Provags-Id: V01U2FsdGVkX18UxvE5zwZJjXEUS6bCN7QDjdrLwWXIbnAyRgQ41iT12zHXB roOysz9d8nuFsr13ToSiesafVrrIs//WVTQILn2PHkb9QzoI7KVAjf1UnXGd Q== Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Subject: FreeBSD 6.2 on Ultra 1 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: Wed, 07 Nov 2007 16:54:40 -0000 Hi there, I'm new to sparc64, but now I got a Ultra 1, which is claimed to be fully supported by Freebsd 6.2, as a present (Sun Ultra 1 SBus 143 MHz with 64 MB memory). When I'm trying to boot the installation-cdrom, I see the following output: ok boot cdrom Boot device: /sbus/espdma@e,8400000/esp@e,8800000/sd@6,0:f File and args: >> FreeBSD/sparc64 boot block Boot path: /sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@6,0:f Boot loader: /boot/loader Consoles: Open Firmware console Boot path set to /sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@6,0:a FreeBSD/sparc64 bootstrap loader, Revision 1.0 (root@s-dallas.cse.buffalo.edu, Fri Jan 12 08:25:13 UTC 2007) bootpath="/sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@6,0:a" Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x531808+0x5bf58 syms=[0x8+0x6c7b0+0x8+0x5a2d9] - Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... nothing to autoload yet. jumping to kernel entry at 0xc0060000. >From this point on nothing happens any more. Can anybody give me a hint, what is my problem here and what could I do? By the way: NetBSD 3.1 is installing without problems and working stable on this machine, but I would prefere FreeBSD because I have quite some experience with it on the i386-platform. Here is the NetBSD dmesg-output: console is sun-keyboard/display Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 3.1 (GENERIC) #0: Tue Oct 31 09:36:38 UTC 2006 builds@b0.netbsd.org:/home/builds/ab/netbsd-3-1-RELEASE/sparc64/200610302053Z-obj/home/builds/ab/netbsd-3-1-RELEASE/src/sys/arch/sparc64/compile/GENERIC total memory = 65536 KB avail memory = 52824 KB bootpath: /sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@0,0 mainbus0 (root): SUNW,Ultra-1: hostid 80762f3a cpu0 at mainbus0: SUNW,UltraSPARC @ 143 MHz, version 0 FPU cpu0: 32K instruction (32 b/l), 16K data (32 b/l), 512K external (64 b/l) timer0 at mainbus0 addr 0xfffc3c00 irq vectors 7f0 and 7f1 sbus0 at mainbus0 addr 0xfffcc000: clock = 25 MHz DVMA map: ff800000 to ffffe000 IOTSB: 102000 to 104000 audiocs0 at sbus0 slot 13 offset 0xc000000 vector 24 ipl 8: CS4231A audio0 at audiocs0: full duplex auxio0 at sbus0 slot 15 offset 0x1900000 flashprom at sbus0 slot 15 offset 0x0 not configured SUNW,fdtwo at sbus0 slot 15 offset 0x1400000 vector 29 ipl 11 not configured clock0 at sbus0 slot 15 offset 0x1200000: mk48t59 zs0 at sbus0 slot 15 offset 0x1100000 vector 28 ipl 12 softpri 6 zstty0 at zs0 channel 0 zstty1 at zs0 channel 1 zs1 at sbus0 slot 15 offset 0x1000000 vector 28 ipl 12 softpri 6 zstty2 at zs1 channel 0 (console input) kbd0 at zstty2 (console input) zstty3 at zs1 channel 1 ms0 at zstty3 wsmouse0 at ms0 mux 0 sc at sbus0 slot 15 offset 0x1300000 not configured SUNW,pll at sbus0 slot 15 offset 0x1304000 not configured dma0 at sbus0 slot 14 offset 0x8400000: DMA rev 2 esp0 at dma0 slot 14 offset 0x8800000 vector 20 ipl 3: ESP200, 40MHz, SCSI ID 7 scsibus0 at esp0: 8 targets, 8 luns per target ledma0 at sbus0 slot 14 offset 0x8400010: DMA rev 2 le0 at ledma0 slot 14 offset 0x8c00000 vector 21 ipl 6: address 08:00:20:76:2f:3a le0: 8 receive buffers, 2 transmit buffers bpp0 at sbus0 slot 14 offset 0xc800000 vector 22 ipl 2: DMA rev 2 cgsix0 at sbus0 slot 2 offset 0x0 vector 5 ipl 5: SUNW,501-2253, 1280 x 1024, rev 11 (console)cgsix0: attached to /dev/fb cgsix0: framebuffer size: 2 MB wsdisplay0 at cgsix0 kbdmux 1: console (std, sun emulation) wsmux1: connecting to wsdisplay0 wsdisplay0: screen 1-3 added (std, sun emulation) pcons at mainbus0 not configured wskbd0 at kbd0: console keyboard, using wsdisplay0 Kernelized RAIDframe activated scsibus0: waiting 2 seconds for devices to settle... sd0 at scsibus0 target 0 lun 0: disk fixed sd0: 2049 MB, 3992 cyl, 9 head, 116 sec, 512 bytes/sect x 4197405 sectors sd0: sync (100.00ns offset 15), 8-bit (10.000MB/s) transfers cd0 at scsibus0 target 6 lun 0: cdrom removable cd0: sync (248.00ns offset 15), 8-bit (4.032MB/s) transfers root on sd0a dumps on sd0b root file system type: ffs Regards, Martin _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066 From owner-freebsd-sparc64@FreeBSD.ORG Wed Nov 7 17:55:51 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFEE116A417 for ; Wed, 7 Nov 2007 17:55:51 +0000 (UTC) (envelope-from ardelean@ww.uni-erlangen.de) Received: from servww6.ww.uni-erlangen.de (servww6.ww.uni-erlangen.de [131.188.238.13]) by mx1.freebsd.org (Postfix) with ESMTP id 5BCB213C4BC for ; Wed, 7 Nov 2007 17:55:49 +0000 (UTC) (envelope-from ardelean@ww.uni-erlangen.de) Received: from localhost (ardelean@localhost) by servww6.ww.uni-erlangen.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id lA7H4V808525; Wed, 7 Nov 2007 18:04:31 +0100 Date: Wed, 7 Nov 2007 18:04:31 +0100 (CET) From: Gheorghe Ardelean To: Martin Roethlein In-Reply-To: <1859732180@web.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-sparc64@freebsd.org Subject: Re: FreeBSD 6.2 on Ultra 1 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, 07 Nov 2007 17:55:52 -0000 On Wed, 7 Nov 2007, Martin Roethlein wrote: > Hi there, > > I'm new to sparc64, but now I got a Ultra 1, which is claimed to be > fully supported by Freebsd 6.2, as a present (Sun Ultra 1 SBus 143 MHz > with 64 MB memory). When I'm trying to boot the installation-cdrom, I > see the following output: Hi, I suppose you do not use a serial console. The SBUS frame buffer (cgsix) found on Ultra1 is not suppported. So please unplug the keyboard and use a serial console (null modem cable to connect your Ultra 1 to an other computer with some terminal software -- a PC is also ok). Regards, Johny. > > > ok boot cdrom > Boot device: /sbus/espdma@e,8400000/esp@e,8800000/sd@6,0:f File and args: > > >> FreeBSD/sparc64 boot block > Boot path: /sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@6,0:f > Boot loader: /boot/loader > Consoles: Open Firmware console > Boot path set to /sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@6,0:a > > FreeBSD/sparc64 bootstrap loader, Revision 1.0 > (root@s-dallas.cse.buffalo.edu, Fri Jan 12 08:25:13 UTC 2007) > bootpath="/sbus@1f,0/espdma@e,8400000/esp@e,8800000/sd@6,0:a" > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x531808+0x5bf58 syms=[0x8+0x6c7b0+0x8+0x5a2d9] > - > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > nothing to autoload yet. > jumping to kernel entry at 0xc0060000. From owner-freebsd-sparc64@FreeBSD.ORG Wed Nov 7 21:21:56 2007 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C976716A41B; Wed, 7 Nov 2007 21:21:56 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id D509113C4A5; Wed, 7 Nov 2007 21:21:55 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.1/8.14.1/ALCHEMY.FRANKEN.DE) with ESMTP id lA7LLYjf015294; Wed, 7 Nov 2007 22:21:35 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.1/8.14.1/Submit) id lA7LLYjA015293; Wed, 7 Nov 2007 22:21:34 +0100 (CET) (envelope-from marius) Date: Wed, 7 Nov 2007 22:21:34 +0100 From: Marius Strobl To: Alan Cox Message-ID: <20071107212134.GL36824@alchemy.franken.de> References: <46FEADFD.8020105@FreeBSD.org> <20071003132944.GA17342@alchemy.franken.de> <200710060222.31023.jhb@freebsd.org> <20071006132620.GF24840@alchemy.franken.de> <472DFC18.3080000@FreeBSD.org> <472E4573.3090708@FreeBSD.org> <20071104224618.GD36824@alchemy.franken.de> <472E54D0.8070807@FreeBSD.org> <473019E8.3070203@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473019E8.3070203@cs.rice.edu> User-Agent: Mutt/1.4.2.3i Cc: alc@FreeBSD.org, Kris Kennaway , freebsd-sparc64@FreeBSD.org, John Baldwin Subject: Re: 7.0 broken on e4500 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, 07 Nov 2007 21:21:56 -0000 On Tue, Nov 06, 2007 at 01:38:16AM -0600, Alan Cox wrote: > Kris Kennaway wrote: > > >Marius Strobl wrote: > > > >>On Sun, Nov 04, 2007 at 11:19:31PM +0100, Kris Kennaway wrote: > >> > >>>Kris Kennaway wrote: > >>> > >>>>Marius Strobl wrote: > >>>> > >>>>>On Sat, Oct 06, 2007 at 02:22:30AM -0400, John Baldwin wrote: > >>>>> > >>>>>>On Wednesday 03 October 2007 09:29:44 am Marius Strobl wrote: > >>>>>> > >>>>>>>On Sat, Sep 29, 2007 at 09:56:45PM +0200, Kris Kennaway wrote: > >>>>>>> > >>>>>>>>I get this early during boot with a CVS kernel (updated from last > >>>>>>> > >>>>>>December): > >>>>>> > >>>>>>>>>FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs > >>>>>>>>>panic: tsb_tte_enter: replacing valid kernel mapping > >>>>>>>>>cpuid = 0 > >>>>>>>>>KDB: enter: panic > >>>>>>>>>[thread pid 0 tid 0 ] > >>>>>>>>>Stopped at kdb_enter+0x68: ta %xcc, 1 > >>>>>>>>>db> wh > >>>>>>>>>Tracing pid 0 tid 0 td 0xc0744f80 > >>>>>>>>>panic() at panic+0x204 > >>>>>>>>>tsb_tte_enter() at tsb_tte_enter+0xdc > >>>>>>>>>pmap_enter_locked() at pmap_enter_locked+0x2d0 > >>>>>>>>>pmap_enter() at pmap_enter+0x64 > >>>>>>>>>kmem_malloc() at kmem_malloc+0x6e0 > >>>>>>>>>page_alloc() at page_alloc+0x28 > >>>>>>>>>uma_large_malloc() at uma_large_malloc+0x44 > >>>>>>>>>malloc() at malloc+0x1b0 > >>>>>>>>>sf_buf_init() at sf_buf_init+0xf8 > >>>>>>>>>mi_startup() at mi_startup+0x18c > >>>>>>>>>btext() at btext+0x34 > >>>>>>>> > >>>>>>>Do you by chance load the new kernel manually via the loader > >>>>>>>prompt, with the old kernel being <= 8MB in size and the new > >>>>>>>one > 8MB? > >>>>>> > >>>>>>I get this panic on an E220R at work, but my "new" kernel is > >>>>>>smaller. > >>>>>> > >>>>>If the actual panic string is "vm_phys_paddr_to_vm_page: paddr > >>>>>is not in any segment" than that's the problem I had in mind when > >>>>>replying to Kris but unfortunately failed to describe the right > >>>>>way around. > >>>>> > >>>>>>>ll /boot/kernel/kernel* /boot/test/kernel* > >>>>>> > >>>>>>-r-xr-xr-x 1 root wheel 7821094 Feb 6 2007 /boot/kernel/kernel > >>>>>>-r-xr-xr-x 1 root wheel 13902501 Feb 6 2007 > >>>>>>/boot/kernel/kernel.symbols > >>>>>>-r-xr-xr-x 1 root wheel 4534968 Oct 6 00:20 /boot/test/kernel > >>>>>>-r-xr-xr-x 1 root wheel 10101980 Oct 6 00:20 > >>>>>>/boot/test/kernel.symbols > >>>>>> > >>>>>>The working kernel (~7MB) is the GENERIC kernel, and the "test" > >>>>>>kernel > >>>>>>is the stripped down kernel for this machine. In my case I'm > >>>>>>panicing in pmap_remove_tte() called from pmap_enter_locked(). I > >>>>>>added some KTR traces to the pmap code to try and investigate, > >>>>>>but I'm guessing the root problem is that the loader doesn't > >>>>>>properly handle telling OFW about needing to change the mappings > >>>>>>when unloading and then loading a new kernel? > >>>>>> > >>>>>>Hmm, it looks like currently the loader doesn't do any sort of MD > >>>>>>callback > >>>>>>when unloading a file, so the loader isn't going to free up the > >>>>>>RAM it asked for from OFW for the old kernel. > >>>>>> > >>>>>Correct, the immediate problem (which I had a patch for somewhere) > >>>>>is that in case the "old" kernel required more TLB slots to be used > >>>>>than the "new" one one can't use the kernel end in order to determine > >>>>>how many slots are used for the kernel map. As you describe the real > >>>>>problem lies within the loader though. The funny thing is that no > >>>>>arch except sparc64 and sun4v seems to rely on the kernel end > >>>>>provided by the loader. > >>>>>If no idea what's the cause of the problem Kris is seeing though. > >>>>> > >>>>>Marius > >>>>> > >>>>> > >>>>FYI one of the e4500's is now booting again but another is still > >>>>failing with the same panic: > >>>> > >>>>FreeBSD 8.0-CURRENT #44: Mon Nov 5 01:52:42 JST 2007 > >>>> root@e4500-2.allbsd.org:/usr/src/sys/sparc64/compile/E4500_2 > >>>>real memory = 9663676416 (9216 MB) > >>>>avail memory = 9433554944 (8996 MB) > >>>>cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>cpu1: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>cpu2: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>cpu3: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>cpu4: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>cpu5: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>cpu6: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>cpu7: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>cpu8: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>cpu9: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs > >>>>panic: tsb_tte_enter: replacing valid kernel mapping > >>>>db> wh > >>>>Tracing pid 0 tid 0 td 0xc056ad30 > >>>>panic() at panic+0x248 > >>>>tsb_tte_enter() at tsb_tte_enter+0xdc > >>>>pmap_enter_locked() at pmap_enter_locked+0x318 > >>>>pmap_enter() at pmap_enter+0x64 > >>>>kmem_malloc() at kmem_malloc+0x644 > >>>>page_alloc() at page_alloc+0x28 > >>>>uma_large_malloc() at uma_large_malloc+0x44 > >>>>malloc() at malloc+0x1a0 > >>>>sf_buf_init() at sf_buf_init+0xe8 > >>>>mi_startup() at mi_startup+0x1e8 > >>>>btext() at btext+0x34 > >>>> > > Can anyone tell me more about the "vm_phys_paddr_to_vm_page: paddr > is not in any segment" panic? > The relevant info should be also above; if one unloads a kernel in the loader and loads another one which occupies fewer TLB slots than the previous one, the excess slots aren't flushed. The kernel in turn relies on the MODINFOMD_KERNEND provided by the loader (i.e. the ekva supplied to pmap_bootstrap()) for calculating the start of KVA however, which doesn't include the excess slots with locked entries entered by the loader. Typical panics look like: cpu0: Sun Microsystems UltraSparc-IIi Processor (440.16 MHz CPU) panic: vm_phys_paddr_to_vm_page: paddr 0x1e01a000 is not in any segment cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x68: ta %xcc, 1 db> bt Tracing pid 0 tid 0 td 0xc06a2780 panic() at panic+0x204 vm_phys_paddr_to_vm_page() at vm_phys_paddr_to_vm_page+0x84 pmap_remove_tte() at pmap_remove_tte+0x44 pmap_enter_locked() at pmap_enter_locked+0x1b4 pmap_enter() at pmap_enter+0x94 kmem_malloc() at kmem_malloc+0x69c page_alloc() at page_alloc+0x28 uma_large_malloc() at uma_large_malloc+0x44 malloc() at malloc+0xc4 sf_buf_init() at sf_buf_init+0xf8 mi_startup() at mi_startup+0x18c btext() at btext+0x34 db> Marius From owner-freebsd-sparc64@FreeBSD.ORG Wed Nov 7 21:26:53 2007 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A736216A46E; Wed, 7 Nov 2007 21:26:53 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id B6EBB13C4AA; Wed, 7 Nov 2007 21:26:49 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47322D98.9090202@FreeBSD.org> Date: Wed, 07 Nov 2007 22:26:48 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Marius Strobl References: <46FEADFD.8020105@FreeBSD.org> <20071003132944.GA17342@alchemy.franken.de> <200710060222.31023.jhb@freebsd.org> <20071006132620.GF24840@alchemy.franken.de> <472DFC18.3080000@FreeBSD.org> <472E4573.3090708@FreeBSD.org> <20071104224618.GD36824@alchemy.franken.de> <472E54D0.8070807@FreeBSD.org> <473019E8.3070203@cs.rice.edu> <20071107212134.GL36824@alchemy.franken.de> In-Reply-To: <20071107212134.GL36824@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@FreeBSD.org, Alan Cox , freebsd-sparc64@FreeBSD.org, John Baldwin Subject: Re: 7.0 broken on e4500 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, 07 Nov 2007 21:26:53 -0000 Marius Strobl wrote: > On Tue, Nov 06, 2007 at 01:38:16AM -0600, Alan Cox wrote: >> Kris Kennaway wrote: >> >>> Marius Strobl wrote: >>> >>>> On Sun, Nov 04, 2007 at 11:19:31PM +0100, Kris Kennaway wrote: >>>> >>>>> Kris Kennaway wrote: >>>>> >>>>>> Marius Strobl wrote: >>>>>> >>>>>>> On Sat, Oct 06, 2007 at 02:22:30AM -0400, John Baldwin wrote: >>>>>>> >>>>>>>> On Wednesday 03 October 2007 09:29:44 am Marius Strobl wrote: >>>>>>>> >>>>>>>>> On Sat, Sep 29, 2007 at 09:56:45PM +0200, Kris Kennaway wrote: >>>>>>>>> >>>>>>>>>> I get this early during boot with a CVS kernel (updated from last >>>>>>>> December): >>>>>>>> >>>>>>>>>>> FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs >>>>>>>>>>> panic: tsb_tte_enter: replacing valid kernel mapping >>>>>>>>>>> cpuid = 0 >>>>>>>>>>> KDB: enter: panic >>>>>>>>>>> [thread pid 0 tid 0 ] >>>>>>>>>>> Stopped at kdb_enter+0x68: ta %xcc, 1 >>>>>>>>>>> db> wh >>>>>>>>>>> Tracing pid 0 tid 0 td 0xc0744f80 >>>>>>>>>>> panic() at panic+0x204 >>>>>>>>>>> tsb_tte_enter() at tsb_tte_enter+0xdc >>>>>>>>>>> pmap_enter_locked() at pmap_enter_locked+0x2d0 >>>>>>>>>>> pmap_enter() at pmap_enter+0x64 >>>>>>>>>>> kmem_malloc() at kmem_malloc+0x6e0 >>>>>>>>>>> page_alloc() at page_alloc+0x28 >>>>>>>>>>> uma_large_malloc() at uma_large_malloc+0x44 >>>>>>>>>>> malloc() at malloc+0x1b0 >>>>>>>>>>> sf_buf_init() at sf_buf_init+0xf8 >>>>>>>>>>> mi_startup() at mi_startup+0x18c >>>>>>>>>>> btext() at btext+0x34 >>>>>>>>> Do you by chance load the new kernel manually via the loader >>>>>>>>> prompt, with the old kernel being <= 8MB in size and the new >>>>>>>>> one > 8MB? >>>>>>>> I get this panic on an E220R at work, but my "new" kernel is >>>>>>>> smaller. >>>>>>>> >>>>>>> If the actual panic string is "vm_phys_paddr_to_vm_page: paddr >>>>>>> is not in any segment" than that's the problem I had in mind when >>>>>>> replying to Kris but unfortunately failed to describe the right >>>>>>> way around. >>>>>>> >>>>>>>>> ll /boot/kernel/kernel* /boot/test/kernel* >>>>>>>> -r-xr-xr-x 1 root wheel 7821094 Feb 6 2007 /boot/kernel/kernel >>>>>>>> -r-xr-xr-x 1 root wheel 13902501 Feb 6 2007 >>>>>>>> /boot/kernel/kernel.symbols >>>>>>>> -r-xr-xr-x 1 root wheel 4534968 Oct 6 00:20 /boot/test/kernel >>>>>>>> -r-xr-xr-x 1 root wheel 10101980 Oct 6 00:20 >>>>>>>> /boot/test/kernel.symbols >>>>>>>> >>>>>>>> The working kernel (~7MB) is the GENERIC kernel, and the "test" >>>>>>>> kernel >>>>>>>> is the stripped down kernel for this machine. In my case I'm >>>>>>>> panicing in pmap_remove_tte() called from pmap_enter_locked(). I >>>>>>>> added some KTR traces to the pmap code to try and investigate, >>>>>>>> but I'm guessing the root problem is that the loader doesn't >>>>>>>> properly handle telling OFW about needing to change the mappings >>>>>>>> when unloading and then loading a new kernel? >>>>>>>> >>>>>>>> Hmm, it looks like currently the loader doesn't do any sort of MD >>>>>>>> callback >>>>>>>> when unloading a file, so the loader isn't going to free up the >>>>>>>> RAM it asked for from OFW for the old kernel. >>>>>>>> >>>>>>> Correct, the immediate problem (which I had a patch for somewhere) >>>>>>> is that in case the "old" kernel required more TLB slots to be used >>>>>>> than the "new" one one can't use the kernel end in order to determine >>>>>>> how many slots are used for the kernel map. As you describe the real >>>>>>> problem lies within the loader though. The funny thing is that no >>>>>>> arch except sparc64 and sun4v seems to rely on the kernel end >>>>>>> provided by the loader. >>>>>>> If no idea what's the cause of the problem Kris is seeing though. >>>>>>> >>>>>>> Marius >>>>>>> >>>>>>> >>>>>> FYI one of the e4500's is now booting again but another is still >>>>>> failing with the same panic: >>>>>> >>>>>> FreeBSD 8.0-CURRENT #44: Mon Nov 5 01:52:42 JST 2007 >>>>>> root@e4500-2.allbsd.org:/usr/src/sys/sparc64/compile/E4500_2 >>>>>> real memory = 9663676416 (9216 MB) >>>>>> avail memory = 9433554944 (8996 MB) >>>>>> cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>>>> cpu1: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>>>> cpu2: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>>>> cpu3: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>>>> cpu4: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>>>> cpu5: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>>>> cpu6: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>>>> cpu7: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>>>> cpu8: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>>>> cpu9: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) >>>>>> FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs >>>>>> panic: tsb_tte_enter: replacing valid kernel mapping >>>>>> db> wh >>>>>> Tracing pid 0 tid 0 td 0xc056ad30 >>>>>> panic() at panic+0x248 >>>>>> tsb_tte_enter() at tsb_tte_enter+0xdc >>>>>> pmap_enter_locked() at pmap_enter_locked+0x318 >>>>>> pmap_enter() at pmap_enter+0x64 >>>>>> kmem_malloc() at kmem_malloc+0x644 >>>>>> page_alloc() at page_alloc+0x28 >>>>>> uma_large_malloc() at uma_large_malloc+0x44 >>>>>> malloc() at malloc+0x1a0 >>>>>> sf_buf_init() at sf_buf_init+0xe8 >>>>>> mi_startup() at mi_startup+0x1e8 >>>>>> btext() at btext+0x34 >>>>>> >> Can anyone tell me more about the "vm_phys_paddr_to_vm_page: paddr >> is not in any segment" panic? >> > > The relevant info should be also above; if one unloads a kernel > in the loader and loads another one which occupies fewer TLB > slots than the previous one, the excess slots aren't flushed. > The kernel in turn relies on the MODINFOMD_KERNEND provided > by the loader (i.e. the ekva supplied to pmap_bootstrap()) for > calculating the start of KVA however, which doesn't include > the excess slots with locked entries entered by the loader. > Typical panics look like: > cpu0: Sun Microsystems UltraSparc-IIi Processor (440.16 MHz CPU) > panic: vm_phys_paddr_to_vm_page: paddr 0x1e01a000 is not in any segment > cpuid = 0 > KDB: enter: panic > [thread pid 0 tid 0 ] > Stopped at kdb_enter+0x68: ta %xcc, 1 > db> bt > Tracing pid 0 tid 0 td 0xc06a2780 > panic() at panic+0x204 > vm_phys_paddr_to_vm_page() at vm_phys_paddr_to_vm_page+0x84 > pmap_remove_tte() at pmap_remove_tte+0x44 > pmap_enter_locked() at pmap_enter_locked+0x1b4 > pmap_enter() at pmap_enter+0x94 > kmem_malloc() at kmem_malloc+0x69c > page_alloc() at page_alloc+0x28 > uma_large_malloc() at uma_large_malloc+0x44 > malloc() at malloc+0xc4 > sf_buf_init() at sf_buf_init+0xf8 > mi_startup() at mi_startup+0x18c > btext() at btext+0x34 > db> > > Marius > > Well, except I'm not unloading the kernel, just letting it boot the default /boot/kernel/kernel. Kris From owner-freebsd-sparc64@FreeBSD.ORG Wed Nov 7 21:33:25 2007 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24B0E16A419; Wed, 7 Nov 2007 21:33:25 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 34CE113C4BA; Wed, 7 Nov 2007 21:33:19 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.1/8.14.1/ALCHEMY.FRANKEN.DE) with ESMTP id lA7LX1QZ015402; Wed, 7 Nov 2007 22:33:01 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.1/8.14.1/Submit) id lA7LX1JU015401; Wed, 7 Nov 2007 22:33:01 +0100 (CET) (envelope-from marius) Date: Wed, 7 Nov 2007 22:33:01 +0100 From: Marius Strobl To: Kris Kennaway Message-ID: <20071107213301.GM36824@alchemy.franken.de> References: <20071003132944.GA17342@alchemy.franken.de> <200710060222.31023.jhb@freebsd.org> <20071006132620.GF24840@alchemy.franken.de> <472DFC18.3080000@FreeBSD.org> <472E4573.3090708@FreeBSD.org> <20071104224618.GD36824@alchemy.franken.de> <472E54D0.8070807@FreeBSD.org> <473019E8.3070203@cs.rice.edu> <20071107212134.GL36824@alchemy.franken.de> <47322D98.9090202@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47322D98.9090202@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: alc@FreeBSD.org, Alan Cox , freebsd-sparc64@FreeBSD.org, John Baldwin Subject: Re: 7.0 broken on e4500 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, 07 Nov 2007 21:33:25 -0000 On Wed, Nov 07, 2007 at 10:26:48PM +0100, Kris Kennaway wrote: > Marius Strobl wrote: > >On Tue, Nov 06, 2007 at 01:38:16AM -0600, Alan Cox wrote: > >>Kris Kennaway wrote: > >> > >>>Marius Strobl wrote: > >>> > >>>>On Sun, Nov 04, 2007 at 11:19:31PM +0100, Kris Kennaway wrote: > >>>> > >>>>>Kris Kennaway wrote: > >>>>> > >>>>>>Marius Strobl wrote: > >>>>>> > >>>>>>>On Sat, Oct 06, 2007 at 02:22:30AM -0400, John Baldwin wrote: > >>>>>>> > >>>>>>>>On Wednesday 03 October 2007 09:29:44 am Marius Strobl wrote: > >>>>>>>> > >>>>>>>>>On Sat, Sep 29, 2007 at 09:56:45PM +0200, Kris Kennaway wrote: > >>>>>>>>> > >>>>>>>>>>I get this early during boot with a CVS kernel (updated from last > >>>>>>>>December): > >>>>>>>> > >>>>>>>>>>>FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs > >>>>>>>>>>>panic: tsb_tte_enter: replacing valid kernel mapping > >>>>>>>>>>>cpuid = 0 > >>>>>>>>>>>KDB: enter: panic > >>>>>>>>>>>[thread pid 0 tid 0 ] > >>>>>>>>>>>Stopped at kdb_enter+0x68: ta %xcc, 1 > >>>>>>>>>>>db> wh > >>>>>>>>>>>Tracing pid 0 tid 0 td 0xc0744f80 > >>>>>>>>>>>panic() at panic+0x204 > >>>>>>>>>>>tsb_tte_enter() at tsb_tte_enter+0xdc > >>>>>>>>>>>pmap_enter_locked() at pmap_enter_locked+0x2d0 > >>>>>>>>>>>pmap_enter() at pmap_enter+0x64 > >>>>>>>>>>>kmem_malloc() at kmem_malloc+0x6e0 > >>>>>>>>>>>page_alloc() at page_alloc+0x28 > >>>>>>>>>>>uma_large_malloc() at uma_large_malloc+0x44 > >>>>>>>>>>>malloc() at malloc+0x1b0 > >>>>>>>>>>>sf_buf_init() at sf_buf_init+0xf8 > >>>>>>>>>>>mi_startup() at mi_startup+0x18c > >>>>>>>>>>>btext() at btext+0x34 > >>>>>>>>>Do you by chance load the new kernel manually via the loader > >>>>>>>>>prompt, with the old kernel being <= 8MB in size and the new > >>>>>>>>>one > 8MB? > >>>>>>>>I get this panic on an E220R at work, but my "new" kernel is > >>>>>>>>smaller. > >>>>>>>> > >>>>>>>If the actual panic string is "vm_phys_paddr_to_vm_page: paddr > >>>>>>>is not in any segment" than that's the problem I had in mind when > >>>>>>>replying to Kris but unfortunately failed to describe the right > >>>>>>>way around. > >>>>>>> > >>>>>>>>>ll /boot/kernel/kernel* /boot/test/kernel* > >>>>>>>>-r-xr-xr-x 1 root wheel 7821094 Feb 6 2007 /boot/kernel/kernel > >>>>>>>>-r-xr-xr-x 1 root wheel 13902501 Feb 6 2007 > >>>>>>>>/boot/kernel/kernel.symbols > >>>>>>>>-r-xr-xr-x 1 root wheel 4534968 Oct 6 00:20 /boot/test/kernel > >>>>>>>>-r-xr-xr-x 1 root wheel 10101980 Oct 6 00:20 > >>>>>>>>/boot/test/kernel.symbols > >>>>>>>> > >>>>>>>>The working kernel (~7MB) is the GENERIC kernel, and the "test" > >>>>>>>>kernel > >>>>>>>>is the stripped down kernel for this machine. In my case I'm > >>>>>>>>panicing in pmap_remove_tte() called from pmap_enter_locked(). I > >>>>>>>>added some KTR traces to the pmap code to try and investigate, > >>>>>>>>but I'm guessing the root problem is that the loader doesn't > >>>>>>>>properly handle telling OFW about needing to change the mappings > >>>>>>>>when unloading and then loading a new kernel? > >>>>>>>> > >>>>>>>>Hmm, it looks like currently the loader doesn't do any sort of MD > >>>>>>>>callback > >>>>>>>>when unloading a file, so the loader isn't going to free up the > >>>>>>>>RAM it asked for from OFW for the old kernel. > >>>>>>>> > >>>>>>>Correct, the immediate problem (which I had a patch for somewhere) > >>>>>>>is that in case the "old" kernel required more TLB slots to be used > >>>>>>>than the "new" one one can't use the kernel end in order to determine > >>>>>>>how many slots are used for the kernel map. As you describe the real > >>>>>>>problem lies within the loader though. The funny thing is that no > >>>>>>>arch except sparc64 and sun4v seems to rely on the kernel end > >>>>>>>provided by the loader. > >>>>>>>If no idea what's the cause of the problem Kris is seeing though. > >>>>>>> > >>>>>>>Marius > >>>>>>> > >>>>>>> > >>>>>>FYI one of the e4500's is now booting again but another is still > >>>>>>failing with the same panic: > >>>>>> > >>>>>>FreeBSD 8.0-CURRENT #44: Mon Nov 5 01:52:42 JST 2007 > >>>>>> root@e4500-2.allbsd.org:/usr/src/sys/sparc64/compile/E4500_2 > >>>>>>real memory = 9663676416 (9216 MB) > >>>>>>avail memory = 9433554944 (8996 MB) > >>>>>>cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>>>cpu1: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>>>cpu2: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>>>cpu3: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>>>cpu4: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>>>cpu5: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>>>cpu6: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>>>cpu7: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>>>cpu8: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>>>cpu9: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >>>>>>FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs > >>>>>>panic: tsb_tte_enter: replacing valid kernel mapping > >>>>>>db> wh > >>>>>>Tracing pid 0 tid 0 td 0xc056ad30 > >>>>>>panic() at panic+0x248 > >>>>>>tsb_tte_enter() at tsb_tte_enter+0xdc > >>>>>>pmap_enter_locked() at pmap_enter_locked+0x318 > >>>>>>pmap_enter() at pmap_enter+0x64 > >>>>>>kmem_malloc() at kmem_malloc+0x644 > >>>>>>page_alloc() at page_alloc+0x28 > >>>>>>uma_large_malloc() at uma_large_malloc+0x44 > >>>>>>malloc() at malloc+0x1a0 > >>>>>>sf_buf_init() at sf_buf_init+0xe8 > >>>>>>mi_startup() at mi_startup+0x1e8 > >>>>>>btext() at btext+0x34 > >>>>>> > >>Can anyone tell me more about the "vm_phys_paddr_to_vm_page: paddr > >>is not in any segment" panic? > >> > > > >The relevant info should be also above; if one unloads a kernel > >in the loader and loads another one which occupies fewer TLB > >slots than the previous one, the excess slots aren't flushed. > >The kernel in turn relies on the MODINFOMD_KERNEND provided > >by the loader (i.e. the ekva supplied to pmap_bootstrap()) for > >calculating the start of KVA however, which doesn't include > >the excess slots with locked entries entered by the loader. > >Typical panics look like: > >cpu0: Sun Microsystems UltraSparc-IIi Processor (440.16 MHz CPU) > >panic: vm_phys_paddr_to_vm_page: paddr 0x1e01a000 is not in any segment > >cpuid = 0 > >KDB: enter: panic > >[thread pid 0 tid 0 ] > >Stopped at kdb_enter+0x68: ta %xcc, 1 > >db> bt > >Tracing pid 0 tid 0 td 0xc06a2780 > >panic() at panic+0x204 > >vm_phys_paddr_to_vm_page() at vm_phys_paddr_to_vm_page+0x84 > >pmap_remove_tte() at pmap_remove_tte+0x44 > >pmap_enter_locked() at pmap_enter_locked+0x1b4 > >pmap_enter() at pmap_enter+0x94 > >kmem_malloc() at kmem_malloc+0x69c > >page_alloc() at page_alloc+0x28 > >uma_large_malloc() at uma_large_malloc+0x44 > >malloc() at malloc+0xc4 > >sf_buf_init() at sf_buf_init+0xf8 > >mi_startup() at mi_startup+0x18c > >btext() at btext+0x34 > >db> > > > >Marius > > > > > > Well, except I'm not unloading the kernel, just letting it boot the > default /boot/kernel/kernel. > Yup, as also written above you're obviously facing another problem. I just initially thought it might be the same. Marius From owner-freebsd-sparc64@FreeBSD.ORG Thu Nov 8 01:05:18 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97CA516A46B for ; Thu, 8 Nov 2007 01:05:18 +0000 (UTC) (envelope-from mosworld@lgphilips-lcd.com) Received: from nospam.lgphilips-lcd.com (relay.lgphilips-lcd.com [203.247.144.180]) by mx1.freebsd.org (Postfix) with SMTP id 2C4E413C4A8 for ; Thu, 8 Nov 2007 01:05:17 +0000 (UTC) (envelope-from mosworld@lgphilips-lcd.com) Received: (snipe 10357 invoked by uid 0); 8 Nov 2007 09:38:14 +0900 Received: from mosworld@lgphilips-lcd.com with Spamsniper 2.94.24 (Processed in 0.026550 secs); Received: from unknown (HELO gwkumi04.lgphilips-lcd.com) (156.147.188.200) by unknown with SMTP; 8 Nov 2007 09:38:14 +0900 X-RCPTTO: freebsd-sparc64@freebsd.org, freebsd-x11@freebsd.org Received: from gwpaju02.lgphilips-lcd.com ([172.19.68.12]) by gwkumi04.lgphilips-lcd.com (Lotus Domino Release 6.5.4FP1) with ESMTP id 2007110809381393-2321737 ; Thu, 8 Nov 2007 09:38:13 +0900 To: freebsd-sparc64@freebsd.org, freebsd-x11@freebsd.org MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: "SUNGBAK KIM" Date: Thu, 8 Nov 2007 09:38:12 +0900 X-MIMETrack: Serialize by Router on GWPAJU02/LGPHILIPS(Release 6.5.4FP1 | June 19, 2005) at 2007-11-08 09:38:13, Serialize complete at 2007-11-08 09:38:13, Itemize by SMTP Server on GWKUMI04/LGPHILIPS(Release 6.5.4FP1|June 19, 2005) at 2007-11-08 ¿ÀÀü 09:38:13, Serialize by Router on GWKUMI04/LGPHILIPS(Release 6.5.4FP1|June 19, 2005) at 2007-11-08 ¿ÀÀü 09:38:14, Serialize complete at 2007-11-08 ¿ÀÀü 09:38:14 Content-Type: text/plain; charset="US-ASCII" Cc: BUMSIK KIM Subject: Xorg 7.3 execution brings crash and rebooting 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, 08 Nov 2007 01:05:18 -0000 Hi? Im using FreeBSD Sparc64, Ultra60 FreeBSD 6.3-PRERELEASE #0: Tue Nov 6 20:43:14 KST 2007 root@xxx.yyy.com:/usr/obj/usr/src/sys/GENERIC real memory = 536870912 (512 MB) avail memory = 510672896 (487 MB) cpu0: Sun Microsystems UltraSparc-II Processor (450.04 MHz CPU) cpu1: Sun Microsystems UltraSparc-II Processor (450.04 MHz CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs I had troubled Xorg 7.2 with keymap, non-USB type6 Korean Layout . so, updated all ports tree and installed Xorg 7.3, but, Any form of Xorg 7.3 execution brings crash and rebooting. /etc/rc.conf moused_enable="YES" moused_port="/dev/cuau3" moused_type="mousesystems" /etc/X11/xorg.conf Section "Device" Identifier "Card0" Driver "sunffb" BusID "SBUS:/SUNW,ffb@1e,0" EndSection What is worse, there are no error or warning message. The moment, when I do "Enter" with "Xorg -configure", system goes rebooting. What can I do more ? ################################################### Kim Sung Bak Senior Research Engineer LG.Philips LCD 1007, Deogeun-ri, Wollong-myeon, Paju-si, Gyeonggi-do, 413-811, Korea Tel: +82-31-933-7594 Fax: +82-31-933-7309 Tel: +82-54-478-1181 Mobile: +82-19-9181-8136 mail: NOSPAMmosworld@lgphilips-lcd.comNOSPAM Homeage: http://www.lgphilips-lcd.com/ #################################################### From owner-freebsd-sparc64@FreeBSD.ORG Thu Nov 8 12:27:14 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20D2A16A41A for ; Thu, 8 Nov 2007 12:27:14 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (w.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id 9CD2713C4BE for ; Thu, 8 Nov 2007 12:27:13 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id lA8Bmxmv098822; Thu, 8 Nov 2007 04:48:59 -0700 (MST) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.1/8.14.1) with ESMTP id lA8Bmt7e023852; Thu, 8 Nov 2007 04:48:55 -0700 (MST) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.1/8.14.1/Submit) id lA8Bmttf023849; Thu, 8 Nov 2007 04:48:55 -0700 (MST) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18226.63399.133928.253631@gromit.timing.com> Date: Thu, 8 Nov 2007 04:48:55 -0700 From: John E Hein To: "SUNGBAK KIM" In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.0.99.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: BUMSIK KIM , freebsd-x11@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: Xorg 7.3 execution brings crash and rebooting 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, 08 Nov 2007 12:27:14 -0000 SUNGBAK KIM wrote at 09:38 +0900 on Nov 8, 2007: > Hi? Im using FreeBSD Sparc64, Ultra60 > > FreeBSD 6.3-PRERELEASE #0: Tue Nov 6 20:43:14 KST 2007 > root@xxx.yyy.com:/usr/obj/usr/src/sys/GENERIC > real memory = 536870912 (512 MB) > avail memory = 510672896 (487 MB) > cpu0: Sun Microsystems UltraSparc-II Processor (450.04 MHz CPU) > cpu1: Sun Microsystems UltraSparc-II Processor (450.04 MHz CPU) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > I had troubled Xorg 7.2 with keymap, non-USB type6 Korean Layout . so, > updated all ports tree and installed Xorg 7.3, > > but, Any form of Xorg 7.3 execution brings crash and rebooting. [snip] > What is worse, there are no error or warning message. The moment, when I > do "Enter" with "Xorg -configure", system goes rebooting. > > What can I do more ? Sounds like a kernel panic. See methods for determining why in the kernel debugging section of the handbook. You could also try to identify which xorg port change triggers the panic (likely the driver, the server or dri). From owner-freebsd-sparc64@FreeBSD.ORG Thu Nov 8 19:15:28 2007 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4237916A4C1; Thu, 8 Nov 2007 19:15:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id ED48613C4BB; Thu, 8 Nov 2007 19:15:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id lA8JFGKR093744; Thu, 8 Nov 2007 14:15:16 -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.14.1/8.14.1) with ESMTP id lA8JFGwR070638; Thu, 8 Nov 2007 14:15:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B34C37302F; Thu, 8 Nov 2007 14:15:15 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071108191515.B34C37302F@freebsd-current.sentex.ca> Date: Thu, 8 Nov 2007 14:15:15 -0500 (EST) X-Virus-Scanned: ClamAV 0.90.2/3781/Fri Jul 27 07:24:10 2007 clamav-milter version 0.91.1 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, 08 Nov 2007 19:15:28 -0000 TB --- 2007-11-08 17:42:24 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-11-08 17:42:24 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-11-08 17:42:24 - cleaning the object tree TB --- 2007-11-08 17:42:50 - checking out the source tree TB --- 2007-11-08 17:42:50 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-11-08 17:42:50 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-11-08 17:49:17 - building world (CFLAGS=-O2 -pipe) TB --- 2007-11-08 17:49:17 - cd /src TB --- 2007-11-08 17:49:17 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 8 17:49:19 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 Thu Nov 8 19:02:05 UTC 2007 TB --- 2007-11-08 19:02:05 - generating LINT kernel config TB --- 2007-11-08 19:02:05 - cd /src/sys/sun4v/conf TB --- 2007-11-08 19:02:05 - /usr/bin/make -B LINT TB --- 2007-11-08 19:02:05 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-11-08 19:02:05 - cd /src TB --- 2007-11-08 19:02:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Nov 8 19:02:05 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hviommu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/identcpu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/in_cksum.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/intr_machdep.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-11-08 19:15:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-11-08 19:15:15 - ERROR: failed to build lint kernel TB --- 2007-11-08 19:15:15 - tinderbox aborted TB --- 0.69 user 2.38 system 5571.12 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-sparc64@FreeBSD.ORG Fri Nov 9 04:04:27 2007 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 114C616A41A; Fri, 9 Nov 2007 04:04:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 613B713C480; Fri, 9 Nov 2007 04:04:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id lA93iYBj032413; Thu, 8 Nov 2007 22:44:34 -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.14.1/8.14.1) with ESMTP id lA93iYMG090001; Thu, 8 Nov 2007 22:44:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EEB227302F; Thu, 8 Nov 2007 22:44:33 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071109034433.EEB227302F@freebsd-current.sentex.ca> Date: Thu, 8 Nov 2007 22:44:33 -0500 (EST) X-Virus-Scanned: ClamAV 0.90.2/3781/Fri Jul 27 07:24:10 2007 clamav-milter version 0.91.1 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: Fri, 09 Nov 2007 04:04:27 -0000 TB --- 2007-11-09 02:11:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-11-09 02:11:22 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-11-09 02:11:23 - cleaning the object tree TB --- 2007-11-09 02:11:42 - checking out the source tree TB --- 2007-11-09 02:11:42 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-11-09 02:11:42 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-11-09 02:19:19 - building world (CFLAGS=-O2 -pipe) TB --- 2007-11-09 02:19:19 - cd /src TB --- 2007-11-09 02:19:19 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 9 02:19:20 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 Nov 9 03:32:06 UTC 2007 TB --- 2007-11-09 03:32:06 - generating LINT kernel config TB --- 2007-11-09 03:32:06 - cd /src/sys/sun4v/conf TB --- 2007-11-09 03:32:06 - /usr/bin/make -B LINT TB --- 2007-11-09 03:32:06 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-11-09 03:32:06 - cd /src TB --- 2007-11-09 03:32:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 9 03:32:06 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hviommu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/identcpu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/in_cksum.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/intr_machdep.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-11-09 03:44:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-11-09 03:44:33 - ERROR: failed to build lint kernel TB --- 2007-11-09 03:44:33 - tinderbox aborted TB --- 0.62 user 2.09 system 5590.78 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-sparc64@FreeBSD.ORG Fri Nov 9 12:13:01 2007 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08CA716A418; Fri, 9 Nov 2007 12:13:01 +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 BD2F513C48A; Fri, 9 Nov 2007 12:13:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id lA9CCrD4024289; Fri, 9 Nov 2007 07:12:53 -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.14.1/8.14.1) with ESMTP id lA9CCqmg027925; Fri, 9 Nov 2007 07:12:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D250A7302F; Fri, 9 Nov 2007 07:12:52 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071109121252.D250A7302F@freebsd-current.sentex.ca> Date: Fri, 9 Nov 2007 07:12:52 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 15:59:09 2007 clamav-milter version 0.91.2 on clamscanner3 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, 09 Nov 2007 12:13:01 -0000 TB --- 2007-11-09 10:39:40 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-11-09 10:39:40 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-11-09 10:39:40 - cleaning the object tree TB --- 2007-11-09 10:39:59 - checking out the source tree TB --- 2007-11-09 10:39:59 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-11-09 10:39:59 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-11-09 10:47:41 - building world (CFLAGS=-O2 -pipe) TB --- 2007-11-09 10:47:41 - cd /src TB --- 2007-11-09 10:47:41 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 9 10:47:43 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 Nov 9 12:00:21 UTC 2007 TB --- 2007-11-09 12:00:21 - generating LINT kernel config TB --- 2007-11-09 12:00:21 - cd /src/sys/sun4v/conf TB --- 2007-11-09 12:00:21 - /usr/bin/make -B LINT TB --- 2007-11-09 12:00:21 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-11-09 12:00:21 - cd /src TB --- 2007-11-09 12:00:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 9 12:00:22 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hviommu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/identcpu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/in_cksum.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/intr_machdep.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-11-09 12:12:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-11-09 12:12:52 - ERROR: failed to build lint kernel TB --- 2007-11-09 12:12:52 - tinderbox aborted TB --- 0.52 user 2.20 system 5592.33 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-sparc64@FreeBSD.ORG Fri Nov 9 15:47:01 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D62CA16A417; Fri, 9 Nov 2007 15:47:01 +0000 (UTC) (envelope-from royce@alaska.net) Received: from hermes.acsalaska.net (hermes.acsalaska.net [209.112.173.230]) by mx1.freebsd.org (Postfix) with ESMTP id 4968D13C4B7; Fri, 9 Nov 2007 15:47:01 +0000 (UTC) (envelope-from royce@alaska.net) Received: from [192.168.254.100] (209-112-218-167-rb1.nwc.dsl.dynamic.acsalaska.net [209.112.218.167]) by hermes.acsalaska.net (8.14.1/8.14.1) with ESMTP id lA9FkpVU099629; Fri, 9 Nov 2007 06:46:52 -0900 (AKST) (envelope-from royce@alaska.net) Message-ID: <47348106.8080001@alaska.net> Date: Fri, 09 Nov 2007 06:47:18 -0900 From: Royce Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Hiroki Sato , freebsd-sparc64@freebsd.org References: <200711011822.25884.linimon@lonesome.com> <472B39A8.3070708@alaska.net> <472DAFBE.9070603@FreeBSD.org> <472E4B8D.2020902@alaska.net> In-Reply-To: <472E4B8D.2020902@alaska.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.63; SA 3.2.3; spamdefang 1.122 Cc: Subject: Re: hardware and package builds 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, 09 Nov 2007 15:47:01 -0000 Royce Williams wrote, on 11/4/2007 1:45 PM: > System: I am willing to buy a 4x U80 for myself and make it available > to the project for package builds. Shipping to Alaska is a bear, so > once the deal goes down, if any other donors could chip in to get it > shipped here, I would appreciate it. I don't want to do this, > however, unless it will actually be useful -- and used. Will it? After talking with Kris and Mark, it appears that the best bang for the buck is to help Hiroki Sato resolve outstanding hardware issues with his e4500s. This will get 10-14 CPUs back online. Hiroki, what hardware or money do you need to get your e4500s back online, in order to improve the speed of package builds for sparc64? Royce -- Royce D. Williams - IP Engineering, ACS http://www.tycho.org/royce/ - PGP: 3FC087DB/1776A531 A prudent question is one half of wisdom. - Francis Bacon From owner-freebsd-sparc64@FreeBSD.ORG Fri Nov 9 20:40:17 2007 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C735F16A46B; Fri, 9 Nov 2007 20:40:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8948013C491; Fri, 9 Nov 2007 20:40:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id lA9KeBT4004832; Fri, 9 Nov 2007 15:40:11 -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.14.1/8.14.1) with ESMTP id lA9KeBFK010467; Fri, 9 Nov 2007 15:40:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 85DF77302F; Fri, 9 Nov 2007 15:40:11 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071109204011.85DF77302F@freebsd-current.sentex.ca> Date: Fri, 9 Nov 2007 15:40:11 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 15:59:09 2007 clamav-milter version 0.91.2 on clamscanner3 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, 09 Nov 2007 20:40:17 -0000 TB --- 2007-11-09 19:07:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-11-09 19:07:17 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-11-09 19:07:17 - cleaning the object tree TB --- 2007-11-09 19:07:36 - checking out the source tree TB --- 2007-11-09 19:07:36 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-11-09 19:07:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-11-09 19:14:09 - building world (CFLAGS=-O2 -pipe) TB --- 2007-11-09 19:14:09 - cd /src TB --- 2007-11-09 19:14:09 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 9 19:14: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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 9 20:27:09 UTC 2007 TB --- 2007-11-09 20:27:09 - generating LINT kernel config TB --- 2007-11-09 20:27:09 - cd /src/sys/sun4v/conf TB --- 2007-11-09 20:27:09 - /usr/bin/make -B LINT TB --- 2007-11-09 20:27:09 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-11-09 20:27:09 - cd /src TB --- 2007-11-09 20:27:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 9 20:27:09 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hviommu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/identcpu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/in_cksum.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/intr_machdep.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-11-09 20:40:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-11-09 20:40:11 - ERROR: failed to build lint kernel TB --- 2007-11-09 20:40:11 - tinderbox aborted TB --- 0.65 user 2.12 system 5574.12 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-sparc64@FreeBSD.ORG Sat Nov 10 05:23:58 2007 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49DFC16A419; Sat, 10 Nov 2007 05:23:58 +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 B5D9C13C4A8; Sat, 10 Nov 2007 05:23:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id lAA594iV040084; Sat, 10 Nov 2007 00:09:04 -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.14.1/8.14.1) with ESMTP id lAA594RD072666; Sat, 10 Nov 2007 00:09:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EC9907302F; Sat, 10 Nov 2007 00:09:03 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071110050903.EC9907302F@freebsd-current.sentex.ca> Date: Sat, 10 Nov 2007 00:09:03 -0500 (EST) X-Virus-Scanned: ClamAV 0.90.2/3781/Fri Jul 27 07:24:10 2007 clamav-milter version 0.91.1 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, 10 Nov 2007 05:23:58 -0000 TB --- 2007-11-10 03:35:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-11-10 03:35:43 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-11-10 03:35:43 - cleaning the object tree TB --- 2007-11-10 03:36:04 - checking out the source tree TB --- 2007-11-10 03:36:04 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-11-10 03:36:04 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-11-10 03:42:47 - building world (CFLAGS=-O2 -pipe) TB --- 2007-11-10 03:42:47 - cd /src TB --- 2007-11-10 03:42:47 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 10 03:42: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 Nov 10 04:56:02 UTC 2007 TB --- 2007-11-10 04:56:02 - generating LINT kernel config TB --- 2007-11-10 04:56:02 - cd /src/sys/sun4v/conf TB --- 2007-11-10 04:56:02 - /usr/bin/make -B LINT TB --- 2007-11-10 04:56:02 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-11-10 04:56:02 - cd /src TB --- 2007-11-10 04:56:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 10 04:56:03 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hviommu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/identcpu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/in_cksum.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/intr_machdep.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-11-10 05:09:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-11-10 05:09:03 - ERROR: failed to build lint kernel TB --- 2007-11-10 05:09:03 - tinderbox aborted TB --- 0.70 user 2.08 system 5599.77 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-sparc64@FreeBSD.ORG Sat Nov 10 14:29:05 2007 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8129C16A417; Sat, 10 Nov 2007 14:29:05 +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 38C6E13C4A6; Sat, 10 Nov 2007 14:29:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id lAADqMdK069314; Sat, 10 Nov 2007 08:52:22 -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.14.1/8.14.1) with ESMTP id lAADqMru074564; Sat, 10 Nov 2007 08:52:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 186127302F; Sat, 10 Nov 2007 08:52:22 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071110135222.186127302F@freebsd-current.sentex.ca> Date: Sat, 10 Nov 2007 08:52:22 -0500 (EST) X-Virus-Scanned: ClamAV 0.90.2/3781/Fri Jul 27 07:24:10 2007 clamav-milter version 0.91.1 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: Sat, 10 Nov 2007 14:29:05 -0000 TB --- 2007-11-10 12:18:55 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-11-10 12:18:55 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-11-10 12:18:55 - cleaning the object tree TB --- 2007-11-10 12:19:18 - checking out the source tree TB --- 2007-11-10 12:19:18 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-11-10 12:19:18 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-11-10 12:26:00 - building world (CFLAGS=-O2 -pipe) TB --- 2007-11-10 12:26:00 - cd /src TB --- 2007-11-10 12:26:00 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 10 12:26:01 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 Nov 10 13:39:13 UTC 2007 TB --- 2007-11-10 13:39:13 - generating LINT kernel config TB --- 2007-11-10 13:39:13 - cd /src/sys/sun4v/conf TB --- 2007-11-10 13:39:13 - /usr/bin/make -B LINT TB --- 2007-11-10 13:39:13 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-11-10 13:39:13 - cd /src TB --- 2007-11-10 13:39:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 10 13:39:13 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hviommu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/identcpu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/in_cksum.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/intr_machdep.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-11-10 13:52:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-11-10 13:52:21 - ERROR: failed to build lint kernel TB --- 2007-11-10 13:52:21 - tinderbox aborted TB --- 0.60 user 2.10 system 5606.45 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-sparc64@FreeBSD.ORG Sat Nov 10 22:21:53 2007 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54D1716A41B; Sat, 10 Nov 2007 22:21:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 06EEC13C49D; Sat, 10 Nov 2007 22:21:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id lAAMLcY9073749; Sat, 10 Nov 2007 17:21:38 -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.14.1/8.14.1) with ESMTP id lAAMLcJY098854; Sat, 10 Nov 2007 17:21:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9236E7302F; Sat, 10 Nov 2007 17:21:38 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071110222138.9236E7302F@freebsd-current.sentex.ca> Date: Sat, 10 Nov 2007 17:21:38 -0500 (EST) X-Virus-Scanned: ClamAV 0.90.2/3781/Fri Jul 27 07:24:10 2007 clamav-milter version 0.91.1 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, 10 Nov 2007 22:21:53 -0000 TB --- 2007-11-10 20:48:18 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-11-10 20:48:18 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-11-10 20:48:18 - cleaning the object tree TB --- 2007-11-10 20:48:43 - checking out the source tree TB --- 2007-11-10 20:48:43 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-11-10 20:48:43 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-11-10 20:55:19 - building world (CFLAGS=-O2 -pipe) TB --- 2007-11-10 20:55:19 - cd /src TB --- 2007-11-10 20:55:19 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 10 20:55:20 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 Nov 10 22:08:15 UTC 2007 TB --- 2007-11-10 22:08:15 - generating LINT kernel config TB --- 2007-11-10 22:08:15 - cd /src/sys/sun4v/conf TB --- 2007-11-10 22:08:15 - /usr/bin/make -B LINT TB --- 2007-11-10 22:08:15 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-11-10 22:08:15 - cd /src TB --- 2007-11-10 22:08:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Nov 10 22:08:15 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/hviommu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/identcpu.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sparc64/sparc64/in_cksum.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/intr_machdep.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-11-10 22:21:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-11-10 22:21:38 - ERROR: failed to build lint kernel TB --- 2007-11-10 22:21:38 - tinderbox aborted TB --- 0.66 user 2.12 system 5599.37 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full