From owner-freebsd-arm@FreeBSD.ORG Sun Feb 5 00:03:53 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBC53106567A for ; Sun, 5 Feb 2012 00:03:53 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 817158FC16 for ; Sun, 5 Feb 2012 00:03:53 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id q14NhKW3050245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Feb 2012 15:43:20 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id q14NhJL3050233; Sat, 4 Feb 2012 15:43:19 -0800 (PST) (envelope-from jmg) Date: Sat, 4 Feb 2012 15:43:19 -0800 From: John-Mark Gurney To: Ian Lepore Message-ID: <20120204234319.GR52468@funkthat.com> Mail-Followup-To: Ian Lepore , Warner Losh , freebsd-arm@freebsd.org References: <1327980703.1662.240.camel@revolution.hippie.lan> <1328025245.1662.289.camel@revolution.hippie.lan> <5FB4965A-66C9-4C99-8B61-5AC605F9ECC5@bsdimp.com> <1328030999.1662.324.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1328030999.1662.324.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 04 Feb 2012 15:43:20 -0800 (PST) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 00:03:53 -0000 Ian Lepore wrote this message on Tue, Jan 31, 2012 at 10:29 -0700: > On Tue, 2012-01-31 at 09:37 -0700, Warner Losh wrote: > > On Jan 31, 2012, at 8:54 AM, Ian Lepore wrote: > > > > > On Mon, 2012-01-30 at 22:39 -0700, Warner Losh wrote: > > >> Hi Ian, > > >> > > >> Do you have any data on what 9.0 does? > > >> > > >> Warner > > > > > > No. Do you have reason to believe it will be different than 8.x? > > > > > > It would be a major effort right now to get anything later than 8.2 > > > built and running on one of our arm platforms. Maybe not as hard as the > > > 6.2 -> 8.2 conversion was, but we're still carrying a lot of diffs from > > > stock FreeBSD that have to be analyzed and merged by hand. Actually > > > before that can even happen I'd have to grab a snapshot of 9.0 and do an > > > svn->Hg conversion to even be able to start merging the diffs (and I'm > > > hardly an Hg expert, but those in the company who are let me know last > > > week that they're just as busy as me, and I'm on my own for this kind of > > > work). It's work I want to do, but I suspect it's going to happen later > > > rather than sooner because product deadlines are beginning to loom and > > > my ability to spend most of my time working on the OS side of things is > > > waning. > > > > > > If there are some specific changes you've got in mind that affect this > > > problem I might be able to backport and test them faster than I could > > > get a full 9.0 or -current build environment working, just point me at > > > them. > > > > I thought that we'd done a root cause of this and had put a fix into the vm system. Lemme look... > > > > ------------------------------------------------------------------------ > > r224049 | marcel | 2011-07-14 20:11:26 -0600 (Thu, 14 Jul 2011) | 2 lines > > > > In pmap_protect(), don't call vm_page_dirty() if the page is unmanaged. > > > > > > ------------------------------------------------------------------------ > > r221844 | cognet | 2011-05-13 09:54:12 -0600 (Fri, 13 May 2011) | 4 lines > > > > In pmap_change_wiring(), use the right argument for pmap_modify_pv(). > > It only worked because the only consumer calls pmap_change_wiring() to remove > > the wiring. > > > > ------------------------------------------------------------------------ > > r212507 | cognet | 2010-09-12 14:46:32 -0600 (Sun, 12 Sep 2010) | 5 lines > > > > In pmap_remove_all(), do not decrease pm_stats.wired_count if the mapping was > > wired, as it's been done later in pmap_nuke_pv(). > > > > Submitted by: Mark Tinguely > > > > > > ------------------------------------------------------------------------ > > r209223 | cognet | 2010-06-15 16:16:02 -0600 (Tue, 15 Jun 2010) | 4 lines > > > > Turn off cache if there's more than one kernel mapping, and one is writable. > > > > Submitted by: Mark Tinguely > > > > ------------------------------------------------------------------------ > > r205028 | raj | 2010-03-11 14:16:54 -0700 (Thu, 11 Mar 2010) | 12 lines > > > > Fix ARM cache handling yet more. > > > > 1) vm_machdep.c: remove the dangling allocations so they do not > > un-necessarily turn off the cache upon consecutive access. > > > > 2) busdma_machdep.c: remove the same amount than shadow mapped. > > > > Reported by: Maks Verver > > Submitted by: Mark Tinguely > > Reviewed by: Grzegorz Bernacki > > MFC after: 3 days > > > > ------------------------------------------------------------------------ > > r203637 | raj | 2010-02-07 13:48:57 -0700 (Sun, 07 Feb 2010) | 19 lines > > > > Improve checking whether an ARM VA has a valid mapping before performing cache > > sync. > > > > VIPT/PIPT caches need valid VA-PA mapping in PTE for a cache operation to > > succeed (unlike VIVT). Prior to this fix pmap was using l2pte_valid() for that > > check, but this is not sufficient as the function merely checks if a PTE > > exists (there can be existing but _invalid_ entries in the table). > > > > A new pmap_has_valid_mapping() routine is introduced to do this job right by > > checking proper PTE flags. > > > > Among other potential problems this cures coherency issues with L2 caches on > > MV-78100. > > > > Submitted by: Grzegorz Bernacki, Piotr Ziecik > > Reviewed, tested by: marcel > > Obtained from: Semihalf > > MFC after: 1 week > > > > > > Only the last two have MFC, so you can start there and see which of these changes are in... > > > > Just thought you might have a reference board that would be easy to test... > > > > Warner > > I think we may have all those changes incorporated except perhaps > r224049; I'll make sure of that. > > r209223 is the change that exposed this situation. > > I'm skeptical that any of the changes you cite (or any change at all in > the pmap layer) will fix the problem, because the problem seems to be > rooted in the fact that the vfs buffer cache establishes a kva mapping > of the buffer pages with the protections set to READ|WRITE|EXEC and > leaves that mapping in place as long as the buffer is in the cache, and > r209223 says that as long as there are multiple mappings of a page with > at least one writable, that page's i-cache and d-cache bits stay off. > (The multiple mappings being the one for the buffer cache that includes > write access and one or more READ|EXEC mappings made by pmap() when the > executable or library is loaded/relocated.) > > If my analysis is correct (and I'm fairly sure, if not 100% positive, > that it is), then it seems to me that the only fix available is going to > be at the vfs layer, and it's going to involve dropping the write access > to the pages in the buffer cache once any physical IO and/or uio > operations needing write access are completed. > > Even if I could figure out a patchset to fix the problem, it's going to > need a lot of input from the vm gurus to answer questions such as what > the performance impact will be to non-VIVT platforms that don't need > this extra work done. If the extra work is expensive enough (and I'm > not sure I could evaluate that properly) it may need to be conditional > on whether the platform needs it. I'm also vaguely uneasy with all this > on a purely philosphical level, since this could end up basically > infecting MI code with a platform-specific concept. What is an easy to figure out if a system we have is effected by this issue? I have a GW2348-4 board running FreeBSD 9.0-RC1 w/ some minor modifications to get pf to work... I think the system is effected by this since userland seems really slow.. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sun Feb 5 15:12:46 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C207F106564A for ; Sun, 5 Feb 2012 15:12:46 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id A272B8FC08 for ; Sun, 5 Feb 2012 15:12:46 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta14.emeryville.ca.mail.comcast.net with comcast id WF9R1i0021wfjNsAEFCmcf; Sun, 05 Feb 2012 15:12:46 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta23.emeryville.ca.mail.comcast.net with comcast id WFCl1i0014NgCEG8jFCl08; Sun, 05 Feb 2012 15:12:46 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q15FCgTh026731; Sun, 5 Feb 2012 08:12:42 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20120204234319.GR52468@funkthat.com> References: <1327980703.1662.240.camel@revolution.hippie.lan> <1328025245.1662.289.camel@revolution.hippie.lan> <5FB4965A-66C9-4C99-8B61-5AC605F9ECC5@bsdimp.com> <1328030999.1662.324.camel@revolution.hippie.lan> <20120204234319.GR52468@funkthat.com> Content-Type: text/plain Date: Sun, 05 Feb 2012 08:12:42 -0700 Message-Id: <1328454762.1733.8.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 15:12:46 -0000 On Sat, 2012-02-04 at 15:43 -0800, John-Mark Gurney wrote: > Ian Lepore wrote this message on Tue, Jan 31, 2012 at 10:29 -0700: > > On Tue, 2012-01-31 at 09:37 -0700, Warner Losh wrote: > > > On Jan 31, 2012, at 8:54 AM, Ian Lepore wrote: > > > > > > > On Mon, 2012-01-30 at 22:39 -0700, Warner Losh wrote: > > > >> Hi Ian, > > > >> > > > >> Do you have any data on what 9.0 does? > > > >> > > > >> Warner > > > > > > > > No. Do you have reason to believe it will be different than 8.x? > > > > > > > > It would be a major effort right now to get anything later than 8.2 > > > > built and running on one of our arm platforms. Maybe not as hard as the > > > > 6.2 -> 8.2 conversion was, but we're still carrying a lot of diffs from > > > > stock FreeBSD that have to be analyzed and merged by hand. Actually > > > > before that can even happen I'd have to grab a snapshot of 9.0 and do an > > > > svn->Hg conversion to even be able to start merging the diffs (and I'm > > > > hardly an Hg expert, but those in the company who are let me know last > > > > week that they're just as busy as me, and I'm on my own for this kind of > > > > work). It's work I want to do, but I suspect it's going to happen later > > > > rather than sooner because product deadlines are beginning to loom and > > > > my ability to spend most of my time working on the OS side of things is > > > > waning. > > > > > > > > If there are some specific changes you've got in mind that affect this > > > > problem I might be able to backport and test them faster than I could > > > > get a full 9.0 or -current build environment working, just point me at > > > > them. > > > > > > I thought that we'd done a root cause of this and had put a fix into the vm system. Lemme look... > > > > > > ------------------------------------------------------------------------ > > > r224049 | marcel | 2011-07-14 20:11:26 -0600 (Thu, 14 Jul 2011) | 2 lines > > > > > > In pmap_protect(), don't call vm_page_dirty() if the page is unmanaged. > > > > > > > > > ------------------------------------------------------------------------ > > > r221844 | cognet | 2011-05-13 09:54:12 -0600 (Fri, 13 May 2011) | 4 lines > > > > > > In pmap_change_wiring(), use the right argument for pmap_modify_pv(). > > > It only worked because the only consumer calls pmap_change_wiring() to remove > > > the wiring. > > > > > > ------------------------------------------------------------------------ > > > r212507 | cognet | 2010-09-12 14:46:32 -0600 (Sun, 12 Sep 2010) | 5 lines > > > > > > In pmap_remove_all(), do not decrease pm_stats.wired_count if the mapping was > > > wired, as it's been done later in pmap_nuke_pv(). > > > > > > Submitted by: Mark Tinguely > > > > > > > > > ------------------------------------------------------------------------ > > > r209223 | cognet | 2010-06-15 16:16:02 -0600 (Tue, 15 Jun 2010) | 4 lines > > > > > > Turn off cache if there's more than one kernel mapping, and one is writable. > > > > > > Submitted by: Mark Tinguely > > > > > > ------------------------------------------------------------------------ > > > r205028 | raj | 2010-03-11 14:16:54 -0700 (Thu, 11 Mar 2010) | 12 lines > > > > > > Fix ARM cache handling yet more. > > > > > > 1) vm_machdep.c: remove the dangling allocations so they do not > > > un-necessarily turn off the cache upon consecutive access. > > > > > > 2) busdma_machdep.c: remove the same amount than shadow mapped. > > > > > > Reported by: Maks Verver > > > Submitted by: Mark Tinguely > > > Reviewed by: Grzegorz Bernacki > > > MFC after: 3 days > > > > > > ------------------------------------------------------------------------ > > > r203637 | raj | 2010-02-07 13:48:57 -0700 (Sun, 07 Feb 2010) | 19 lines > > > > > > Improve checking whether an ARM VA has a valid mapping before performing cache > > > sync. > > > > > > VIPT/PIPT caches need valid VA-PA mapping in PTE for a cache operation to > > > succeed (unlike VIVT). Prior to this fix pmap was using l2pte_valid() for that > > > check, but this is not sufficient as the function merely checks if a PTE > > > exists (there can be existing but _invalid_ entries in the table). > > > > > > A new pmap_has_valid_mapping() routine is introduced to do this job right by > > > checking proper PTE flags. > > > > > > Among other potential problems this cures coherency issues with L2 caches on > > > MV-78100. > > > > > > Submitted by: Grzegorz Bernacki, Piotr Ziecik > > > Reviewed, tested by: marcel > > > Obtained from: Semihalf > > > MFC after: 1 week > > > > > > > > > Only the last two have MFC, so you can start there and see which of these changes are in... > > > > > > Just thought you might have a reference board that would be easy to test... > > > > > > Warner > > > > I think we may have all those changes incorporated except perhaps > > r224049; I'll make sure of that. > > > > r209223 is the change that exposed this situation. > > > > I'm skeptical that any of the changes you cite (or any change at all in > > the pmap layer) will fix the problem, because the problem seems to be > > rooted in the fact that the vfs buffer cache establishes a kva mapping > > of the buffer pages with the protections set to READ|WRITE|EXEC and > > leaves that mapping in place as long as the buffer is in the cache, and > > r209223 says that as long as there are multiple mappings of a page with > > at least one writable, that page's i-cache and d-cache bits stay off. > > (The multiple mappings being the one for the buffer cache that includes > > write access and one or more READ|EXEC mappings made by pmap() when the > > executable or library is loaded/relocated.) > > > > If my analysis is correct (and I'm fairly sure, if not 100% positive, > > that it is), then it seems to me that the only fix available is going to > > be at the vfs layer, and it's going to involve dropping the write access > > to the pages in the buffer cache once any physical IO and/or uio > > operations needing write access are completed. > > > > Even if I could figure out a patchset to fix the problem, it's going to > > need a lot of input from the vm gurus to answer questions such as what > > the performance impact will be to non-VIVT platforms that don't need > > this extra work done. If the extra work is expensive enough (and I'm > > not sure I could evaluate that properly) it may need to be conditional > > on whether the platform needs it. I'm also vaguely uneasy with all this > > on a purely philosphical level, since this could end up basically > > infecting MI code with a platform-specific concept. > > What is an easy to figure out if a system we have is effected by this > issue? I have a GW2348-4 board running FreeBSD 9.0-RC1 w/ some minor > modifications to get pf to work... > > I think the system is effected by this since userland seems really slow.. > > Thanks. > In the original mail thread the author used the following trivial test program and posted some examples of what good/bad numbers would be int main() { int i = 0; do ++i; while(i > 0); return 0; } Based on my experiences, a way to test this would be to put that executable on the system and reboot. After it boots, run the test a few times and note the runtime. Then do "cat test_program >/dev/null" and run it again. If the performance drops dramatically after the cat, you're seeing the same problem. I've started on the process of trying to replicate my results in 9.0, but it's going to take me some time to get our custom mods into 9 to get a bootable arm box. (I lost yesterday morning to a failed disk drive, and decided it's time for a new development/build machine, and lost the rest of the day to shopping/dreaming/drooling over fast new hardware.) -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Feb 6 05:48:17 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 190DC1065670 for ; Mon, 6 Feb 2012 05:48:17 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id E8F918FC14 for ; Mon, 6 Feb 2012 05:48:16 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta10.emeryville.ca.mail.comcast.net with comcast id WVfa1i0031GXsucAAVoGXL; Mon, 06 Feb 2012 05:48:16 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta07.emeryville.ca.mail.comcast.net with comcast id WVoF1i0094NgCEG8UVoFKL; Mon, 06 Feb 2012 05:48:16 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q165mDj3027203; Sun, 5 Feb 2012 22:48:13 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20120204234319.GR52468@funkthat.com> References: <1327980703.1662.240.camel@revolution.hippie.lan> <1328025245.1662.289.camel@revolution.hippie.lan> <5FB4965A-66C9-4C99-8B61-5AC605F9ECC5@bsdimp.com> <1328030999.1662.324.camel@revolution.hippie.lan> <20120204234319.GR52468@funkthat.com> Content-Type: text/plain Date: Sun, 05 Feb 2012 22:48:12 -0700 Message-Id: <1328507292.3546.67.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 05:48:17 -0000 On Sat, 2012-02-04 at 15:43 -0800, John-Mark Gurney wrote: > Ian Lepore wrote this message on Tue, Jan 31, 2012 at 10:29 -0700: > > On Tue, 2012-01-31 at 09:37 -0700, Warner Losh wrote: > > > On Jan 31, 2012, at 8:54 AM, Ian Lepore wrote: > > > > > > > On Mon, 2012-01-30 at 22:39 -0700, Warner Losh wrote: > > > >> Hi Ian, > > > >> > > > >> Do you have any data on what 9.0 does? > > > >> > > > >> Warner > > > > > > > > No. Do you have reason to believe it will be different than 8.x? > > > > > > > > It would be a major effort right now to get anything later than 8.2 > > > > built and running on one of our arm platforms. Maybe not as hard as the > > > > 6.2 -> 8.2 conversion was, but we're still carrying a lot of diffs from > > > > stock FreeBSD that have to be analyzed and merged by hand. Actually > > > > before that can even happen I'd have to grab a snapshot of 9.0 and do an > > > > svn->Hg conversion to even be able to start merging the diffs (and I'm > > > > hardly an Hg expert, but those in the company who are let me know last > > > > week that they're just as busy as me, and I'm on my own for this kind of > > > > work). It's work I want to do, but I suspect it's going to happen later > > > > rather than sooner because product deadlines are beginning to loom and > > > > my ability to spend most of my time working on the OS side of things is > > > > waning. > > > > > > > > If there are some specific changes you've got in mind that affect this > > > > problem I might be able to backport and test them faster than I could > > > > get a full 9.0 or -current build environment working, just point me at > > > > them. > > > > > > I thought that we'd done a root cause of this and had put a fix into the vm system. Lemme look... > > > > > > ------------------------------------------------------------------------ > > > r224049 | marcel | 2011-07-14 20:11:26 -0600 (Thu, 14 Jul 2011) | 2 lines > > > > > > In pmap_protect(), don't call vm_page_dirty() if the page is unmanaged. > > > > > > > > > ------------------------------------------------------------------------ > > > r221844 | cognet | 2011-05-13 09:54:12 -0600 (Fri, 13 May 2011) | 4 lines > > > > > > In pmap_change_wiring(), use the right argument for pmap_modify_pv(). > > > It only worked because the only consumer calls pmap_change_wiring() to remove > > > the wiring. > > > > > > ------------------------------------------------------------------------ > > > r212507 | cognet | 2010-09-12 14:46:32 -0600 (Sun, 12 Sep 2010) | 5 lines > > > > > > In pmap_remove_all(), do not decrease pm_stats.wired_count if the mapping was > > > wired, as it's been done later in pmap_nuke_pv(). > > > > > > Submitted by: Mark Tinguely > > > > > > > > > ------------------------------------------------------------------------ > > > r209223 | cognet | 2010-06-15 16:16:02 -0600 (Tue, 15 Jun 2010) | 4 lines > > > > > > Turn off cache if there's more than one kernel mapping, and one is writable. > > > > > > Submitted by: Mark Tinguely > > > > > > ------------------------------------------------------------------------ > > > r205028 | raj | 2010-03-11 14:16:54 -0700 (Thu, 11 Mar 2010) | 12 lines > > > > > > Fix ARM cache handling yet more. > > > > > > 1) vm_machdep.c: remove the dangling allocations so they do not > > > un-necessarily turn off the cache upon consecutive access. > > > > > > 2) busdma_machdep.c: remove the same amount than shadow mapped. > > > > > > Reported by: Maks Verver > > > Submitted by: Mark Tinguely > > > Reviewed by: Grzegorz Bernacki > > > MFC after: 3 days > > > > > > ------------------------------------------------------------------------ > > > r203637 | raj | 2010-02-07 13:48:57 -0700 (Sun, 07 Feb 2010) | 19 lines > > > > > > Improve checking whether an ARM VA has a valid mapping before performing cache > > > sync. > > > > > > VIPT/PIPT caches need valid VA-PA mapping in PTE for a cache operation to > > > succeed (unlike VIVT). Prior to this fix pmap was using l2pte_valid() for that > > > check, but this is not sufficient as the function merely checks if a PTE > > > exists (there can be existing but _invalid_ entries in the table). > > > > > > A new pmap_has_valid_mapping() routine is introduced to do this job right by > > > checking proper PTE flags. > > > > > > Among other potential problems this cures coherency issues with L2 caches on > > > MV-78100. > > > > > > Submitted by: Grzegorz Bernacki, Piotr Ziecik > > > Reviewed, tested by: marcel > > > Obtained from: Semihalf > > > MFC after: 1 week > > > > > > > > > Only the last two have MFC, so you can start there and see which of these changes are in... > > > > > > Just thought you might have a reference board that would be easy to test... > > > > > > Warner > > > > I think we may have all those changes incorporated except perhaps > > r224049; I'll make sure of that. > > > > r209223 is the change that exposed this situation. > > > > I'm skeptical that any of the changes you cite (or any change at all in > > the pmap layer) will fix the problem, because the problem seems to be > > rooted in the fact that the vfs buffer cache establishes a kva mapping > > of the buffer pages with the protections set to READ|WRITE|EXEC and > > leaves that mapping in place as long as the buffer is in the cache, and > > r209223 says that as long as there are multiple mappings of a page with > > at least one writable, that page's i-cache and d-cache bits stay off. > > (The multiple mappings being the one for the buffer cache that includes > > write access and one or more READ|EXEC mappings made by pmap() when the > > executable or library is loaded/relocated.) > > > > If my analysis is correct (and I'm fairly sure, if not 100% positive, > > that it is), then it seems to me that the only fix available is going to > > be at the vfs layer, and it's going to involve dropping the write access > > to the pages in the buffer cache once any physical IO and/or uio > > operations needing write access are completed. > > > > Even if I could figure out a patchset to fix the problem, it's going to > > need a lot of input from the vm gurus to answer questions such as what > > the performance impact will be to non-VIVT platforms that don't need > > this extra work done. If the extra work is expensive enough (and I'm > > not sure I could evaluate that properly) it may need to be conditional > > on whether the platform needs it. I'm also vaguely uneasy with all this > > on a purely philosphical level, since this could end up basically > > infecting MI code with a platform-specific concept. > > What is an easy to figure out if a system we have is effected by this > issue? I have a GW2348-4 board running FreeBSD 9.0-RC1 w/ some minor > modifications to get pf to work... > > I think the system is effected by this since userland seems really slow.. > > Thanks. > Okay, I've just confirmed that the problem as I described it above still exists in 9.0 ... # uname -a FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #7: Mon Feb 6 04:38:59 UTC 2012 root@revolution.hippie.lan:/usr/obj/arm.arm/usr/src/sys/TFLEX arm # /usr/tsc/bin/testsimple Elapsed 0.782453 # /usr/tsc/bin/testsimple Elapsed 0.782539 # cat /usr/tsc/bin/testsimple >/dev/null # /usr/tsc/bin/testsimple Elapsed 10.090336 # /usr/tsc/bin/testsimple Elapsed 10.090611 The testsimple program is just a little loop that repeatedly assigns a volatile variable (had to fool the optimizer into generating some code). I statically linked it to avoid any variability based on the race between paging and readahead when loading shared libs. I'm just showing here that the base problem still exists: when executable pages get into the vfs buffer cache they (semi-)permanently lose their i-cache bit. I also applied my patches from the start of this thread and re-tested and they appear to still be a usable workaround for the problem in 9. But they are just a workaround, we need to figure out a real fix for this. (I had to enable the #if in ffs_read() as well as the one in ffs_write() for this test, since my quick 'cat' test is reading the file to get it into the cache.) -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Feb 6 11:06:56 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 091041065674 for ; Mon, 6 Feb 2012 11:06:56 +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 EB0028FC0C for ; Mon, 6 Feb 2012 11:06:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q16B6tI6007751 for ; Mon, 6 Feb 2012 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q16B6t0w007749 for freebsd-arm@FreeBSD.org; Mon, 6 Feb 2012 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Feb 2012 11:06:55 GMT Message-Id: <201202061106.q16B6t0w007749@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 11:06:56 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/160431 arm [busdma] [patch] Disable interrupts during busdma cach o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/156814 arm OpenRD Ultimate does not boot on DB-88F6XXX or SHEEVAP o arm/156496 arm [patch] Minor bugfixes and enhancements to mmc and mmc o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) o arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/154189 arm lang/perl5.12 doesn't build on arm o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 16 problems total. From owner-freebsd-arm@FreeBSD.ORG Tue Feb 7 16:00:32 2012 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F7091065679 for ; Tue, 7 Feb 2012 16:00:32 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7DD438FC18 for ; Tue, 7 Feb 2012 16:00:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q17G0WwN052102 for ; Tue, 7 Feb 2012 16:00:32 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q17G0WnH052101; Tue, 7 Feb 2012 16:00:32 GMT (envelope-from gnats) Date: Tue, 7 Feb 2012 16:00:32 GMT Message-Id: <201202071600.q17G0WnH052101@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: arm/161492: commit references a PR X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:00:32 -0000 The following reply was made to PR arm/161492; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/161492: commit references a PR Date: Tue, 7 Feb 2012 15:50:49 +0000 (UTC) Author: cognet Date: Tue Feb 7 15:50:14 2012 New Revision: 231131 URL: http://svn.freebsd.org/changeset/base/231131 Log: MFC r226441 and r226443 r226441: Explicitely set ARM_RAS_START and ARM_RAS_END once the cacheline or the page has been allocated, or we could end up using random values, and bad things could happen. PR: arm/161492 Submitted by: Ian Lepore r226443: Fix 2 bugs : - A race condition could happen if two threads were using RAS at the same time as the code didn't reset RAS_END, the RAS code could believe we were not in a RAS, when we were in fact. - Using signed value logic to compare addresses wasn't such a good idea. Many thanks to Ian to investigate on these issues. Pointy hat to: cognet PR: arm/161498 Submitted by: Ian Lepore Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70C6F106564A for ; Tue, 7 Feb 2012 16:00:36 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5F37B8FC19 for ; Tue, 7 Feb 2012 16:00:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q17G0aq0052114 for ; Tue, 7 Feb 2012 16:00:36 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q17G0amN052113; Tue, 7 Feb 2012 16:00:36 GMT (envelope-from gnats) Date: Tue, 7 Feb 2012 16:00:36 GMT Message-Id: <201202071600.q17G0amN052113@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: arm/161498: commit references a PR X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:00:36 -0000 The following reply was made to PR arm/161498; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/161498: commit references a PR Date: Tue, 7 Feb 2012 15:50:49 +0000 (UTC) Author: cognet Date: Tue Feb 7 15:50:14 2012 New Revision: 231131 URL: http://svn.freebsd.org/changeset/base/231131 Log: MFC r226441 and r226443 r226441: Explicitely set ARM_RAS_START and ARM_RAS_END once the cacheline or the page has been allocated, or we could end up using random values, and bad things could happen. PR: arm/161492 Submitted by: Ian Lepore r226443: Fix 2 bugs : - A race condition could happen if two threads were using RAS at the same time as the code didn't reset RAS_END, the RAS code could believe we were not in a RAS, when we were in fact. - Using signed value logic to compare addresses wasn't such a good idea. Many thanks to Ian to investigate on these issues. Pointy hat to: cognet PR: arm/161498 Submitted by: Ian Lepore Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E363106566C for ; Tue, 7 Feb 2012 16:10:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4CB9B8FC16 for ; Tue, 7 Feb 2012 16:10:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q17GAHx2060997 for ; Tue, 7 Feb 2012 16:10:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q17GAH6k060996; Tue, 7 Feb 2012 16:10:17 GMT (envelope-from gnats) Date: Tue, 7 Feb 2012 16:10:17 GMT Message-Id: <201202071610.q17GAH6k060996@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: arm/161492: commit references a PR X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:10:17 -0000 The following reply was made to PR arm/161492; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/161492: commit references a PR Date: Tue, 7 Feb 2012 16:07:38 +0000 (UTC) Author: cognet Date: Tue Feb 7 16:07:29 2012 New Revision: 231132 URL: http://svn.freebsd.org/changeset/base/231132 Log: MFC r226441 and r226443 r226441: Explicitely set ARM_RAS_START and ARM_RAS_END once the cacheline or the page has been allocated, or we could end up using random values, and bad things could happen. PR: arm/161492 Submitted by: Ian Lepore r226443: Fix 2 bugs : - A race condition could happen if two threads were using RAS at the same time as the code didn't reset RAS_END, the RAS code could believe we were not in a RAS, when we were in fact. - Using signed value logic to compare addresses wasn't such a good idea. Many thanks to Ian to investigate on these issues. Pointy hat to: cognet PR: arm/161498 Submitted by: Ian Lepore Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E0BD1065676 for ; Tue, 7 Feb 2012 16:10:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F0B508FC17 for ; Tue, 7 Feb 2012 16:10:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q17GAIXj061002 for ; Tue, 7 Feb 2012 16:10:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q17GAI9L061001; Tue, 7 Feb 2012 16:10:18 GMT (envelope-from gnats) Date: Tue, 7 Feb 2012 16:10:18 GMT Message-Id: <201202071610.q17GAI9L061001@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: arm/161498: commit references a PR X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:10:19 -0000 The following reply was made to PR arm/161498; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/161498: commit references a PR Date: Tue, 7 Feb 2012 16:07:39 +0000 (UTC) Author: cognet Date: Tue Feb 7 16:07:29 2012 New Revision: 231132 URL: http://svn.freebsd.org/changeset/base/231132 Log: MFC r226441 and r226443 r226441: Explicitely set ARM_RAS_START and ARM_RAS_END once the cacheline or the page has been allocated, or we could end up using random values, and bad things could happen. PR: arm/161492 Submitted by: Ian Lepore r226443: Fix 2 bugs : - A race condition could happen if two threads were using RAS at the same time as the code didn't reset RAS_END, the RAS code could believe we were not in a RAS, when we were in fact. - Using signed value logic to compare addresses wasn't such a good idea. Many thanks to Ian to investigate on these issues. Pointy hat to: cognet PR: arm/161498 Submitted by: Ian Lepore Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 460A2106567E for ; Tue, 7 Feb 2012 23:36:07 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id ECADE8FC15 for ; Tue, 7 Feb 2012 23:36:06 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so7692464vbb.13 for ; Tue, 07 Feb 2012 15:36:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uR9X5ms/T0TyBtmEmxd1pX3D7QGXbNzcCsRRY/oUv2s=; b=htqu2mTSJZhDzd4kNJf0+i7YShgnibySWPZanhlowlVOlyCcpKMplw0c5WByOFO1sp JZ6MwEPRoXEM1VcYBCfJyKGth6MUFq3GqHGelvTRGedZJCD756qoaUgt73yzy7LfVyKd W7gtZYZF2W4gD946fFi3WgW2D9YFqINsJKdJM= MIME-Version: 1.0 Received: by 10.52.66.225 with SMTP id i1mr4999689vdt.65.1328656215360; Tue, 07 Feb 2012 15:10:15 -0800 (PST) Received: by 10.220.156.206 with HTTP; Tue, 7 Feb 2012 15:10:15 -0800 (PST) In-Reply-To: <1328507292.3546.67.camel@revolution.hippie.lan> References: <1327980703.1662.240.camel@revolution.hippie.lan> <1328025245.1662.289.camel@revolution.hippie.lan> <5FB4965A-66C9-4C99-8B61-5AC605F9ECC5@bsdimp.com> <1328030999.1662.324.camel@revolution.hippie.lan> <20120204234319.GR52468@funkthat.com> <1328507292.3546.67.camel@revolution.hippie.lan> Date: Tue, 7 Feb 2012 17:10:15 -0600 Message-ID: From: Mark Tinguely To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 23:36:07 -0000 On Sun, Feb 5, 2012 at 11:48 PM, Ian Lepore > Okay, I've just confirmed that the problem as I described it above still > exists in 9.0 ... > > =A0 =A0 =A0 =A0# uname -a > =A0 =A0 =A0 =A0FreeBSD =A09.0-RELEASE FreeBSD 9.0-RELEASE #7: Mon Feb =A0= 6 04:38:59 > =A0 =A0 =A0 =A0UTC 2012 > =A0 =A0 =A0 =A0root@revolution.hippie.lan:/usr/obj/arm.arm/usr/src/sys/TF= LEX > =A0 =A0 =A0 =A0arm > > =A0 =A0 =A0 =A0# /usr/tsc/bin/testsimple > =A0 =A0 =A0 =A0Elapsed 0.782453 > =A0 =A0 =A0 =A0# /usr/tsc/bin/testsimple > =A0 =A0 =A0 =A0Elapsed 0.782539 > > =A0 =A0 =A0 =A0# cat /usr/tsc/bin/testsimple >/dev/null > > =A0 =A0 =A0 =A0# /usr/tsc/bin/testsimple > =A0 =A0 =A0 =A0Elapsed 10.090336 > =A0 =A0 =A0 =A0# /usr/tsc/bin/testsimple > =A0 =A0 =A0 =A0Elapsed 10.090611 > > The testsimple program is just a little loop that repeatedly assigns a > volatile variable (had to fool the optimizer into generating some code). > I statically linked it to avoid any variability based on the race > between paging and readahead when loading shared libs. =A0I'm just showin= g > here that the base problem still exists: =A0when executable pages get int= o > the vfs buffer cache they (semi-)permanently lose their i-cache bit. > > I also applied my patches from the start of this thread and re-tested > and they appear to still be a usable workaround for the problem in 9. > But they are just a workaround, we need to figure out a real fix for > this. =A0(I had to enable the #if in ffs_read() as well as the one in > ffs_write() for this test, since my quick 'cat' test is reading the file > to get it into the cache.) > > -- Ian I dug out my files from that era. I was looking at the cases where the page is marked executable and writable= : 1) were they shared or single mappings? 2) are all the shared mappings executable? 3) was the page mapped several time in one process? 4) was the all the writers a kernel process? 5) was there many kernel mappings I was think something like (pardon the bad formatting) if (exec && (exec =3D=3D entries + kentries) && #ifndef test1 (writable =3D=3D 0 || (writable =3D=3D kwritable)) && #else (writable =3D=3D 0 || (writable =3D=3D 1 && kwritable =3D=3D 1)) && #endif (ncaches =3D=3D 0)) { return; /* bypass the cache fix routine */ } this test is just before the comment that says /* * check if the user duplicate mapping has * been removed. */ I never felt brave enough with this test though. --Mark. From owner-freebsd-arm@FreeBSD.ORG Wed Feb 8 18:57:20 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16212106568B for ; Wed, 8 Feb 2012 18:57:20 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id E94828FC08 for ; Wed, 8 Feb 2012 18:57:19 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta12.emeryville.ca.mail.comcast.net with comcast id XUS91i0061afHeLACWxKfw; Wed, 08 Feb 2012 18:57:19 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta17.emeryville.ca.mail.comcast.net with comcast id XWxJ1i00j4NgCEG8dWxKxS; Wed, 08 Feb 2012 18:57:19 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q18IvGRE031215; Wed, 8 Feb 2012 11:57:16 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Mark Tinguely In-Reply-To: References: <1327980703.1662.240.camel@revolution.hippie.lan> <1328025245.1662.289.camel@revolution.hippie.lan> <5FB4965A-66C9-4C99-8B61-5AC605F9ECC5@bsdimp.com> <1328030999.1662.324.camel@revolution.hippie.lan> <20120204234319.GR52468@funkthat.com> <1328507292.3546.67.camel@revolution.hippie.lan> Content-Type: text/plain Date: Wed, 08 Feb 2012 11:57:16 -0700 Message-Id: <1328727436.81779.27.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:57:20 -0000 On Tue, 2012-02-07 at 17:10 -0600, Mark Tinguely wrote: > On Sun, Feb 5, 2012 at 11:48 PM, Ian Lepore > > > Okay, I've just confirmed that the problem as I described it above still > > exists in 9.0 ... > > > > # uname -a > > FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #7: Mon Feb 6 04:38:59 > > UTC 2012 > > root@revolution.hippie.lan:/usr/obj/arm.arm/usr/src/sys/TFLEX > > arm > > > > # /usr/tsc/bin/testsimple > > Elapsed 0.782453 > > # /usr/tsc/bin/testsimple > > Elapsed 0.782539 > > > > # cat /usr/tsc/bin/testsimple >/dev/null > > > > # /usr/tsc/bin/testsimple > > Elapsed 10.090336 > > # /usr/tsc/bin/testsimple > > Elapsed 10.090611 > > > > The testsimple program is just a little loop that repeatedly assigns a > > volatile variable (had to fool the optimizer into generating some code). > > I statically linked it to avoid any variability based on the race > > between paging and readahead when loading shared libs. I'm just showing > > here that the base problem still exists: when executable pages get into > > the vfs buffer cache they (semi-)permanently lose their i-cache bit. > > > > I also applied my patches from the start of this thread and re-tested > > and they appear to still be a usable workaround for the problem in 9. > > But they are just a workaround, we need to figure out a real fix for > > this. (I had to enable the #if in ffs_read() as well as the one in > > ffs_write() for this test, since my quick 'cat' test is reading the file > > to get it into the cache.) > > > > -- Ian > > > I dug out my files from that era. > > I was looking at the cases where the page is marked executable and writable: > > 1) were they shared or single mappings? > 2) are all the shared mappings executable? > 3) was the page mapped several time in one process? > 4) was the all the writers a kernel process? > 5) was there many kernel mappings > > I was think something like (pardon the bad formatting) > > if (exec && (exec == entries + kentries) && > #ifndef test1 > (writable == 0 || (writable == kwritable)) && > #else > (writable == 0 || (writable == 1 && kwritable == 1)) && > #endif > (ncaches == 0)) { > return; /* bypass the cache fix routine */ > } > > this test is just before the comment that says > > /* > * check if the user duplicate mapping has > * been removed. > */ > > I never felt brave enough with this test though. > > --Mark. There are always one or more mappings which are read+exec which are the actual executable mappings established by rtld-elf/map_object.c for a shared lib or by code in kern/kern_exec.c for an app, plus one kernel mapping that is read+exec+write which was established by the code path which begins with ffs_read() or ffs_write() and ends with a copy of the disk blocks in the buffer cache with write access still enabled in the mapping after the IO is done. The patch to map_object.c in my original posting fixes most of the problem, but more as a workaround than a proper fix. It avoids calling ffs_read() as part of loading a shared lib, so the pages never end up in the buffer cache and a writable mapping of the pages doesn't linger. But there are other legitimate things you can do with an app or shared lib that invoke the ffs_read()/ffs_write() code, such as copy it or read/write it for other reasons, and that results in the lingering writable mapping. I believe the arm pmap code is correct; it is managing the cachability of the pages properly according to the permissions that exist in the mappings. The problem is leaving write permissions in place for the buffer cache mapping of the page after the IO is done and there's no longer a need to write to the page. Trying to infer that situation from the pmap code and make the page cacheable because it appears that the only writable mapping might be the buffer cache mapping feels like a very dangerous thing to do. The right fix, I believe, is to not leave writable mappings for pages in the buffer cache when there is no IO in progress. If changing the permissions after the IO is done is an expensive operation, then we may need some sort of compile-time flag that indicates a VIVT architecture so we can avoid the extra expense on platforms that don't need it. I'd like to prove my point in that last paragraph with a patch that I could claim works, but I can't figure out without help from a VM guru where is the right place to drop the write permission on the pages. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Feb 8 19:31:37 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29BC9106566C for ; Wed, 8 Feb 2012 19:31:37 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm2.bullet.mail.bf1.yahoo.com (nm2.bullet.mail.bf1.yahoo.com [98.139.212.161]) by mx1.freebsd.org (Postfix) with SMTP id B08E98FC13 for ; Wed, 8 Feb 2012 19:31:36 +0000 (UTC) Received: from [98.139.215.142] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 08 Feb 2012 19:18:55 -0000 Received: from [98.139.211.204] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 08 Feb 2012 19:18:55 -0000 Received: from [127.0.0.1] by smtp213.mail.bf1.yahoo.com with NNFMP; 08 Feb 2012 19:18:54 -0000 X-Yahoo-Newman-Id: 974321.12697.bm@smtp213.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: yWR3LWkVM1mins5yDG2a9AU.jjwodMfRFQqv7r1R3FcLAaG Q9aBzQ.XXFVJ9qFByJ3J_WkMtzyRiy0pKQ6hWxqWBMGl71EAMcTF_Ao9tMlG O4i0W6syujheBVmBI8UgTJLFbSi9sHQx..RN02f_brakBWUMQ_7bVysvbC5p 4I4cfXL7oEXd2VLnDUe43Np.uICrT5YzCfdLvdPCrP5gcjV8xpGS1xqm4BAf He.xz0L4fwfTSaPg.4qRirGXGadMtK6djyftcHl2dloT_9I06LG9kbj3FEVi kZvdApIw4bPdbxEkos0PJ6oc20GRejjeGgjmempdRCKMHi3LI0V7A.Vd8IaX JenFtaNG.4NP9a_Zw0Lw7uo4FsyezauMttDlcTw__g3VJn1JbAI9OI2Yf1u4 W2GNMuqBhYgjksxgdyBf94Re1JpYQO3_nubQUPkYKvAljrbxM8d.YCqLlmVd JKqDAVZBBi1SO4WF..bk15wnxqQMNnOcgTQMRJZcqUbydARstmLyOx7vxWla cCxIFjjiFOV6G0ooD9EfwMRwC_ukXZU1nxrzH_OCdbmFaH3DAvdyDLoiYqcg lyHymAt2VgFTESo4BdFvMNahtKJcGcYYGmvJTp9BLzS14Iu0lBpc1tgaJp23 M_z0.vtUmzVGe_VccXMRlGtXGFTYoD3i6ELCiMNTBayKmMmFwfCGTXea93Tj .ArNZVEIRJxdjUzAbwEcTsSkLs7ZwMg3XTIx2OjG.Lird9qoCpQ-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.22] (se@81.173.141.140 with plain) by smtp213.mail.bf1.yahoo.com with SMTP; 08 Feb 2012 11:18:54 -0800 PST Message-ID: <4F32CA9D.4000305@freebsd.org> Date: Wed, 08 Feb 2012 20:18:53 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: FreeBSD on Raspberry PI? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 19:31:37 -0000 The Raspberry PI has just been announced to become available at the end of February and I'm just curious, whether it will be a good platform for FreeBSD. It is based on a Broadcom BCM2835 (ARM1176JZFS) for which a Technical Reference Manual and a "BCM2835 ARM Peripherals" document exist. The latter has just been announced in: http://www.raspberrypi.org/archives/615 and can be found at: http://dmkenr5gtnd8f.cloudfront.net/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf Linux sources have also been published: https://github.com/raspberrypi/linux I'm going to get one, anyway, and would like to support a porting effort to this platform. Video will not be possible, I'm afraid, but the Raspberry PI looks like a nice base for a cheap, small server (800k Dhrystones, some 60% of a BeagleBone AFAIK). Regards, STefan From owner-freebsd-arm@FreeBSD.ORG Thu Feb 9 11:15:54 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37573106564A; Thu, 9 Feb 2012 11:15:54 +0000 (UTC) (envelope-from adutkowski@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 547178FC0A; Thu, 9 Feb 2012 11:15:53 +0000 (UTC) Received: by eaan10 with SMTP id n10so589453eaa.13 for ; Thu, 09 Feb 2012 03:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sIdQYGC8+uSm6cpDN044kV6w4KQksNxoo/x0GFmjqXU=; b=dFBASQObN9CmVR7HPyXUNMm4vDN5/a6lRIqH/6iGR2UEp+TgBc/yAFw8rmsoq+68Fq hdRCoyv/NvNHcnU6bYhAFWjee7f2IpJ4nnlNMgc3YyiZSgRByRIHTaoJXF5BgbP0eSFK EY5UgrBiQYYwphF8ophDDFYZnXpveKXxgz8xY= MIME-Version: 1.0 Received: by 10.14.47.68 with SMTP id s44mr486080eeb.11.1328786151695; Thu, 09 Feb 2012 03:15:51 -0800 (PST) Received: by 10.213.21.201 with HTTP; Thu, 9 Feb 2012 03:15:51 -0800 (PST) In-Reply-To: <4F32CA9D.4000305@freebsd.org> References: <4F32CA9D.4000305@freebsd.org> Date: Thu, 9 Feb 2012 12:15:51 +0100 Message-ID: From: Aleksander Dutkowski To: Stefan Esser , freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: FreeBSD on Raspberry PI? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 11:15:54 -0000 Hi Stefan! Here you have some topics from freebsd-hackers: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-November/036742.html http://lists.freebsd.org/pipermail/freebsd-hackers/2011-November/036748.html I am going to purchase one, so I could also help porting:) On Wed, Feb 8, 2012 at 8:18 PM, Stefan Esser wrote: > The Raspberry PI has just been announced to become available at the end > of February and I'm just curious, whether it will be a good platform > for FreeBSD. > > It is based on a Broadcom BCM2835 (ARM1176JZFS) for which a Technical > Reference Manual and a "BCM2835 ARM Peripherals" document exist. The > latter has just been announced in: > > http://www.raspberrypi.org/archives/615 and can > > be found at: > > http://dmkenr5gtnd8f.cloudfront.net/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf > > Linux sources have also been published: > > https://github.com/raspberrypi/linux > > I'm going to get one, anyway, and would like to support a porting > effort to this platform. Video will not be possible, I'm afraid, but > the Raspberry PI looks like a nice base for a cheap, small server > (800k Dhrystones, some 60% of a BeagleBone AFAIK). > > Regards, STefan > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- pozdrawiam Aleksander Dutkowski From owner-freebsd-arm@FreeBSD.ORG Thu Feb 9 13:26:52 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C602106564A for ; Thu, 9 Feb 2012 13:26:52 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm16.bullet.mail.sp2.yahoo.com (nm16.bullet.mail.sp2.yahoo.com [98.139.91.86]) by mx1.freebsd.org (Postfix) with SMTP id 766818FC08 for ; Thu, 9 Feb 2012 13:26:52 +0000 (UTC) Received: from [98.139.91.63] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 09 Feb 2012 13:14:08 -0000 Received: from [208.71.42.190] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 09 Feb 2012 13:14:08 -0000 Received: from [127.0.0.1] by smtp201.mail.gq1.yahoo.com with NNFMP; 09 Feb 2012 13:14:08 -0000 X-Yahoo-Newman-Id: 727966.32154.bm@smtp201.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Ym4zIFwVM1n6p_IX8.dDZrsgAgCvnn1N.31lm5urukpRdhZ tOeAib2fhdi1NHNw9TR7eyGr8M5RetihPnl0mxgDI_kjl9euenBVRnoUdJWw gKNZiwEQKjSbAWv3.nU8fw8dGXxDJKRPLiywLeP7XHhys04HgbtF1PiaHD15 jQ6cxfAhgkFeZJfwJXqceN2ThMMneasD5fBjpiGZaog.4IjdFes75WmEzriH 24SIKk7TXh_ZYT1F_qWHnDfnB6EmPQI.V0XK67pTPRCFSFkNbwsno4OOFgKb 1Vtt2DTgLqOtQmJ.OxOetop3_UMX7QcW3Be2aQxpYtnzP0I8vGKaAeizgYPk f_UiK5TyHqwmWaPiEevsNdL24p_6bh.vEFbzhW8QTyfjTe.4Pai5HTF89PtV FaikMIGigSRt3._ObKk589G5C0PldqC9iCMf5dRjdgzdsBfZy8mTTxavPTyP cuNnuXwZtqvMeCE_uEZMDdwZhK6UPPUwm.kw6D13oXSVybq2hRRpbgC9IQhd IPGdwNV5i3LDOAGEIcnrMUG1Y6ZKpqVx30Pbsqfxc4A-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.22] (se@81.173.156.255 with plain) by smtp201.mail.gq1.yahoo.com with SMTP; 09 Feb 2012 05:14:08 -0800 PST Message-ID: <4F33C6A0.8020301@freebsd.org> Date: Thu, 09 Feb 2012 14:14:08 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Aleksander Dutkowski References: <4F32CA9D.4000305@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD on Raspberry PI? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 13:26:52 -0000 Am 09.02.2012 12:15, schrieb Aleksander Dutkowski: > Hi Stefan! > > Here you have some topics from freebsd-hackers: > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-November/036742.html > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-November/036748.html > > I am going to purchase one, so I could also help porting:) Hi Aleksander, thank you for the pointers to previous threads. I just had missed them in the hackers lists and did not find anything in the ARM list, so I asked. The threads indicate that a number of people was interested in looking at the Raspberry PI, and I think it is a great chance to have support for that device, since I expect it to become a huge success (not economically, since it is built by a non-profit organization, but with respect to visibility in the public). But we'll probably never be able to take advantage of its multi-media features, which is too bad. Well, then lets wait for the device to actually appear in the wild and see whether it is practical to start porting. AFAIK, there is just a (hard-coded) trivial primary boot loader that accesses the SD card. But having Linux (and Linux sources) for this device on a SD card will help to understand the hardware and then we'll see how far we get ;-) Regards, STefan From owner-freebsd-arm@FreeBSD.ORG Sat Feb 11 01:19:45 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BD821065672; Sat, 11 Feb 2012 01:19:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 38AC48FC21; Sat, 11 Feb 2012 01:19:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q1B1JfsZ020095; Fri, 10 Feb 2012 20:19:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q1B1JfGB020086; Sat, 11 Feb 2012 01:19:41 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 11 Feb 2012 01:19:41 GMT Message-Id: <201202110119.q1B1JfGB020086@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 01:19:45 -0000 TB --- 2012-02-10 23:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-02-10 23:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-02-10 23:40:00 - cleaning the object tree TB --- 2012-02-10 23:40:00 - cvsupping the source tree TB --- 2012-02-10 23:40:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-02-10 23:40:24 - building world TB --- 2012-02-10 23:40:24 - CROSS_BUILD_TESTING=YES TB --- 2012-02-10 23:40:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-10 23:40:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-10 23:40:24 - SRCCONF=/dev/null TB --- 2012-02-10 23:40:24 - TARGET=arm TB --- 2012-02-10 23:40:24 - TARGET_ARCH=arm TB --- 2012-02-10 23:40:24 - TZ=UTC TB --- 2012-02-10 23:40:24 - __MAKE_CONF=/dev/null TB --- 2012-02-10 23:40:24 - cd /src TB --- 2012-02-10 23:40:24 - /usr/bin/make -B buildworld >>> World build started on Fri Feb 10 23:40:24 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Feb 11 00:32:55 UTC 2012 TB --- 2012-02-11 00:32:55 - cd /src/sys/arm/conf TB --- 2012-02-11 00:32:55 - /usr/sbin/config -m AVILA TB --- 2012-02-11 00:32:55 - building AVILA kernel TB --- 2012-02-11 00:32:55 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 00:32:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 00:32:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 00:32:55 - SRCCONF=/dev/null TB --- 2012-02-11 00:32:55 - TARGET=arm TB --- 2012-02-11 00:32:55 - TARGET_ARCH=arm TB --- 2012-02-11 00:32:55 - TZ=UTC TB --- 2012-02-11 00:32:55 - __MAKE_CONF=/dev/null TB --- 2012-02-11 00:32:55 - cd /src TB --- 2012-02-11 00:32:55 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Sat Feb 11 00:32:55 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AVILA completed on Sat Feb 11 00:35:55 UTC 2012 TB --- 2012-02-11 00:35:55 - cd /src/sys/arm/conf TB --- 2012-02-11 00:35:55 - /usr/sbin/config -m BWCT TB --- 2012-02-11 00:35:55 - building BWCT kernel TB --- 2012-02-11 00:35:55 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 00:35:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 00:35:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 00:35:55 - SRCCONF=/dev/null TB --- 2012-02-11 00:35:55 - TARGET=arm TB --- 2012-02-11 00:35:55 - TARGET_ARCH=arm TB --- 2012-02-11 00:35:55 - TZ=UTC TB --- 2012-02-11 00:35:55 - __MAKE_CONF=/dev/null TB --- 2012-02-11 00:35:55 - cd /src TB --- 2012-02-11 00:35:55 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sat Feb 11 00:35:55 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Sat Feb 11 00:38:00 UTC 2012 TB --- 2012-02-11 00:38:00 - cd /src/sys/arm/conf TB --- 2012-02-11 00:38:00 - /usr/sbin/config -m CAMBRIA TB --- 2012-02-11 00:38:00 - building CAMBRIA kernel TB --- 2012-02-11 00:38:00 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 00:38:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 00:38:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 00:38:00 - SRCCONF=/dev/null TB --- 2012-02-11 00:38:00 - TARGET=arm TB --- 2012-02-11 00:38:00 - TARGET_ARCH=arm TB --- 2012-02-11 00:38:00 - TZ=UTC TB --- 2012-02-11 00:38:00 - __MAKE_CONF=/dev/null TB --- 2012-02-11 00:38:00 - cd /src TB --- 2012-02-11 00:38:00 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Sat Feb 11 00:38:00 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CAMBRIA completed on Sat Feb 11 00:40:59 UTC 2012 TB --- 2012-02-11 00:40:59 - cd /src/sys/arm/conf TB --- 2012-02-11 00:40:59 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-02-11 00:40:59 - building CNS11XXNAS kernel TB --- 2012-02-11 00:40:59 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 00:40:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 00:40:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 00:40:59 - SRCCONF=/dev/null TB --- 2012-02-11 00:40:59 - TARGET=arm TB --- 2012-02-11 00:40:59 - TARGET_ARCH=arm TB --- 2012-02-11 00:40:59 - TZ=UTC TB --- 2012-02-11 00:40:59 - __MAKE_CONF=/dev/null TB --- 2012-02-11 00:40:59 - cd /src TB --- 2012-02-11 00:40:59 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Sat Feb 11 00:40:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Sat Feb 11 00:43:32 UTC 2012 TB --- 2012-02-11 00:43:32 - cd /src/sys/arm/conf TB --- 2012-02-11 00:43:32 - /usr/sbin/config -m CRB TB --- 2012-02-11 00:43:32 - building CRB kernel TB --- 2012-02-11 00:43:32 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 00:43:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 00:43:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 00:43:32 - SRCCONF=/dev/null TB --- 2012-02-11 00:43:32 - TARGET=arm TB --- 2012-02-11 00:43:32 - TARGET_ARCH=arm TB --- 2012-02-11 00:43:32 - TZ=UTC TB --- 2012-02-11 00:43:32 - __MAKE_CONF=/dev/null TB --- 2012-02-11 00:43:32 - cd /src TB --- 2012-02-11 00:43:32 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Sat Feb 11 00:43:32 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CRB completed on Sat Feb 11 00:47:21 UTC 2012 TB --- 2012-02-11 00:47:21 - cd /src/sys/arm/conf TB --- 2012-02-11 00:47:21 - /usr/sbin/config -m DB-78XXX TB --- 2012-02-11 00:47:21 - building DB-78XXX kernel TB --- 2012-02-11 00:47:21 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 00:47:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 00:47:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 00:47:21 - SRCCONF=/dev/null TB --- 2012-02-11 00:47:21 - TARGET=arm TB --- 2012-02-11 00:47:21 - TARGET_ARCH=arm TB --- 2012-02-11 00:47:21 - TZ=UTC TB --- 2012-02-11 00:47:21 - __MAKE_CONF=/dev/null TB --- 2012-02-11 00:47:21 - cd /src TB --- 2012-02-11 00:47:21 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Sat Feb 11 00:47:21 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Sat Feb 11 00:49:59 UTC 2012 TB --- 2012-02-11 00:49:59 - cd /src/sys/arm/conf TB --- 2012-02-11 00:49:59 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-02-11 00:49:59 - building DB-88F5XXX kernel TB --- 2012-02-11 00:49:59 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 00:49:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 00:49:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 00:49:59 - SRCCONF=/dev/null TB --- 2012-02-11 00:49:59 - TARGET=arm TB --- 2012-02-11 00:49:59 - TARGET_ARCH=arm TB --- 2012-02-11 00:49:59 - TZ=UTC TB --- 2012-02-11 00:49:59 - __MAKE_CONF=/dev/null TB --- 2012-02-11 00:49:59 - cd /src TB --- 2012-02-11 00:49:59 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Sat Feb 11 00:49:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Sat Feb 11 00:52:36 UTC 2012 TB --- 2012-02-11 00:52:36 - cd /src/sys/arm/conf TB --- 2012-02-11 00:52:36 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-02-11 00:52:36 - building DB-88F6XXX kernel TB --- 2012-02-11 00:52:36 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 00:52:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 00:52:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 00:52:36 - SRCCONF=/dev/null TB --- 2012-02-11 00:52:36 - TARGET=arm TB --- 2012-02-11 00:52:36 - TARGET_ARCH=arm TB --- 2012-02-11 00:52:36 - TZ=UTC TB --- 2012-02-11 00:52:36 - __MAKE_CONF=/dev/null TB --- 2012-02-11 00:52:36 - cd /src TB --- 2012-02-11 00:52:36 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Sat Feb 11 00:52:36 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Sat Feb 11 00:55:19 UTC 2012 TB --- 2012-02-11 00:55:19 - cd /src/sys/arm/conf TB --- 2012-02-11 00:55:19 - /usr/sbin/config -m DOCKSTAR TB --- 2012-02-11 00:55:19 - building DOCKSTAR kernel TB --- 2012-02-11 00:55:19 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 00:55:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 00:55:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 00:55:19 - SRCCONF=/dev/null TB --- 2012-02-11 00:55:19 - TARGET=arm TB --- 2012-02-11 00:55:19 - TARGET_ARCH=arm TB --- 2012-02-11 00:55:19 - TZ=UTC TB --- 2012-02-11 00:55:19 - __MAKE_CONF=/dev/null TB --- 2012-02-11 00:55:19 - cd /src TB --- 2012-02-11 00:55:19 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Sat Feb 11 00:55:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Sat Feb 11 00:58:17 UTC 2012 TB --- 2012-02-11 00:58:17 - cd /src/sys/arm/conf TB --- 2012-02-11 00:58:17 - /usr/sbin/config -m EP80219 TB --- 2012-02-11 00:58:17 - building EP80219 kernel TB --- 2012-02-11 00:58:17 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 00:58:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 00:58:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 00:58:17 - SRCCONF=/dev/null TB --- 2012-02-11 00:58:17 - TARGET=arm TB --- 2012-02-11 00:58:17 - TARGET_ARCH=arm TB --- 2012-02-11 00:58:17 - TZ=UTC TB --- 2012-02-11 00:58:17 - __MAKE_CONF=/dev/null TB --- 2012-02-11 00:58:17 - cd /src TB --- 2012-02-11 00:58:17 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Sat Feb 11 00:58:17 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EP80219 completed on Sat Feb 11 01:01:07 UTC 2012 TB --- 2012-02-11 01:01:07 - cd /src/sys/arm/conf TB --- 2012-02-11 01:01:07 - /usr/sbin/config -m GUMSTIX TB --- 2012-02-11 01:01:07 - building GUMSTIX kernel TB --- 2012-02-11 01:01:07 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 01:01:07 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 01:01:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 01:01:07 - SRCCONF=/dev/null TB --- 2012-02-11 01:01:07 - TARGET=arm TB --- 2012-02-11 01:01:07 - TARGET_ARCH=arm TB --- 2012-02-11 01:01:07 - TZ=UTC TB --- 2012-02-11 01:01:07 - __MAKE_CONF=/dev/null TB --- 2012-02-11 01:01:07 - cd /src TB --- 2012-02-11 01:01:07 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Sat Feb 11 01:01:07 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GUMSTIX completed on Sat Feb 11 01:03:25 UTC 2012 TB --- 2012-02-11 01:03:25 - cd /src/sys/arm/conf TB --- 2012-02-11 01:03:25 - /usr/sbin/config -m HL200 TB --- 2012-02-11 01:03:25 - building HL200 kernel TB --- 2012-02-11 01:03:25 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 01:03:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 01:03:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 01:03:25 - SRCCONF=/dev/null TB --- 2012-02-11 01:03:25 - TARGET=arm TB --- 2012-02-11 01:03:25 - TARGET_ARCH=arm TB --- 2012-02-11 01:03:25 - TZ=UTC TB --- 2012-02-11 01:03:25 - __MAKE_CONF=/dev/null TB --- 2012-02-11 01:03:25 - cd /src TB --- 2012-02-11 01:03:25 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Sat Feb 11 01:03:26 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for HL200 completed on Sat Feb 11 01:06:03 UTC 2012 TB --- 2012-02-11 01:06:03 - cd /src/sys/arm/conf TB --- 2012-02-11 01:06:03 - /usr/sbin/config -m HL201 TB --- 2012-02-11 01:06:03 - building HL201 kernel TB --- 2012-02-11 01:06:03 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 01:06:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 01:06:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 01:06:03 - SRCCONF=/dev/null TB --- 2012-02-11 01:06:03 - TARGET=arm TB --- 2012-02-11 01:06:03 - TARGET_ARCH=arm TB --- 2012-02-11 01:06:03 - TZ=UTC TB --- 2012-02-11 01:06:03 - __MAKE_CONF=/dev/null TB --- 2012-02-11 01:06:03 - cd /src TB --- 2012-02-11 01:06:03 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Sat Feb 11 01:06:03 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for HL201 completed on Sat Feb 11 01:08:14 UTC 2012 TB --- 2012-02-11 01:08:14 - cd /src/sys/arm/conf TB --- 2012-02-11 01:08:14 - /usr/sbin/config -m IQ31244 TB --- 2012-02-11 01:08:14 - building IQ31244 kernel TB --- 2012-02-11 01:08:14 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 01:08:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 01:08:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 01:08:14 - SRCCONF=/dev/null TB --- 2012-02-11 01:08:14 - TARGET=arm TB --- 2012-02-11 01:08:14 - TARGET_ARCH=arm TB --- 2012-02-11 01:08:14 - TZ=UTC TB --- 2012-02-11 01:08:14 - __MAKE_CONF=/dev/null TB --- 2012-02-11 01:08:14 - cd /src TB --- 2012-02-11 01:08:14 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Sat Feb 11 01:08:14 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for IQ31244 completed on Sat Feb 11 01:11:32 UTC 2012 TB --- 2012-02-11 01:11:32 - cd /src/sys/arm/conf TB --- 2012-02-11 01:11:32 - /usr/sbin/config -m KB920X TB --- 2012-02-11 01:11:32 - building KB920X kernel TB --- 2012-02-11 01:11:32 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 01:11:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 01:11:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 01:11:32 - SRCCONF=/dev/null TB --- 2012-02-11 01:11:32 - TARGET=arm TB --- 2012-02-11 01:11:32 - TARGET_ARCH=arm TB --- 2012-02-11 01:11:32 - TZ=UTC TB --- 2012-02-11 01:11:32 - __MAKE_CONF=/dev/null TB --- 2012-02-11 01:11:32 - cd /src TB --- 2012-02-11 01:11:32 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Sat Feb 11 01:11:32 UTC 2012 >>> 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 [...] ld -Bshareable -d -warn-common -o nullfs.ko.debug nullfs.kld objcopy --only-keep-debug nullfs.ko.debug nullfs.ko.symbols objcopy --strip-debug --add-gnu-debuglink=nullfs.ko.symbols nullfs.ko.debug nullfs.ko ===> oce (all) cc -O -pipe -DSMP -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/oce/../../dev/oce -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/oce/../../dev/oce/oce_if.c cc1: warnings being treated as errors /src/sys/modules/oce/../../dev/oce/oce_if.c: In function 'oce_attach_ifp': /src/sys/modules/oce/../../dev/oce/oce_if.c:1647: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/oce. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-11 01:19:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-11 01:19:40 - ERROR: failed to build KB920X kernel TB --- 2012-02-11 01:19:40 - 4638.69 user 932.46 system 5980.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Feb 11 07:32:31 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B89E1065670; Sat, 11 Feb 2012 07:32:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 289E58FC14; Sat, 11 Feb 2012 07:32:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q1B7WUIc011326; Sat, 11 Feb 2012 02:32:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q1B7WU9Y011304; Sat, 11 Feb 2012 07:32:30 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 11 Feb 2012 07:32:30 GMT Message-Id: <201202110732.q1B7WU9Y011304@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 07:32:31 -0000 TB --- 2012-02-11 05:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-02-11 05:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-02-11 05:50:00 - cleaning the object tree TB --- 2012-02-11 05:50:25 - cvsupping the source tree TB --- 2012-02-11 05:50:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-02-11 05:50:46 - building world TB --- 2012-02-11 05:50:46 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 05:50:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 05:50:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 05:50:46 - SRCCONF=/dev/null TB --- 2012-02-11 05:50:46 - TARGET=arm TB --- 2012-02-11 05:50:46 - TARGET_ARCH=arm TB --- 2012-02-11 05:50:46 - TZ=UTC TB --- 2012-02-11 05:50:46 - __MAKE_CONF=/dev/null TB --- 2012-02-11 05:50:46 - cd /src TB --- 2012-02-11 05:50:46 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 11 05:50:48 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Feb 11 06:44:15 UTC 2012 TB --- 2012-02-11 06:44:15 - cd /src/sys/arm/conf TB --- 2012-02-11 06:44:15 - /usr/sbin/config -m AVILA TB --- 2012-02-11 06:44:15 - building AVILA kernel TB --- 2012-02-11 06:44:15 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 06:44:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 06:44:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 06:44:15 - SRCCONF=/dev/null TB --- 2012-02-11 06:44:15 - TARGET=arm TB --- 2012-02-11 06:44:15 - TARGET_ARCH=arm TB --- 2012-02-11 06:44:15 - TZ=UTC TB --- 2012-02-11 06:44:15 - __MAKE_CONF=/dev/null TB --- 2012-02-11 06:44:15 - cd /src TB --- 2012-02-11 06:44:15 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Sat Feb 11 06:44:15 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AVILA completed on Sat Feb 11 06:47:18 UTC 2012 TB --- 2012-02-11 06:47:18 - cd /src/sys/arm/conf TB --- 2012-02-11 06:47:18 - /usr/sbin/config -m BWCT TB --- 2012-02-11 06:47:18 - building BWCT kernel TB --- 2012-02-11 06:47:18 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 06:47:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 06:47:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 06:47:18 - SRCCONF=/dev/null TB --- 2012-02-11 06:47:18 - TARGET=arm TB --- 2012-02-11 06:47:18 - TARGET_ARCH=arm TB --- 2012-02-11 06:47:18 - TZ=UTC TB --- 2012-02-11 06:47:18 - __MAKE_CONF=/dev/null TB --- 2012-02-11 06:47:18 - cd /src TB --- 2012-02-11 06:47:18 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sat Feb 11 06:47:18 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Sat Feb 11 06:49:54 UTC 2012 TB --- 2012-02-11 06:49:54 - cd /src/sys/arm/conf TB --- 2012-02-11 06:49:54 - /usr/sbin/config -m CAMBRIA TB --- 2012-02-11 06:49:54 - building CAMBRIA kernel TB --- 2012-02-11 06:49:54 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 06:49:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 06:49:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 06:49:54 - SRCCONF=/dev/null TB --- 2012-02-11 06:49:54 - TARGET=arm TB --- 2012-02-11 06:49:54 - TARGET_ARCH=arm TB --- 2012-02-11 06:49:54 - TZ=UTC TB --- 2012-02-11 06:49:54 - __MAKE_CONF=/dev/null TB --- 2012-02-11 06:49:54 - cd /src TB --- 2012-02-11 06:49:54 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Sat Feb 11 06:49:54 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CAMBRIA completed on Sat Feb 11 06:52:50 UTC 2012 TB --- 2012-02-11 06:52:50 - cd /src/sys/arm/conf TB --- 2012-02-11 06:52:50 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-02-11 06:52:50 - building CNS11XXNAS kernel TB --- 2012-02-11 06:52:50 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 06:52:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 06:52:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 06:52:50 - SRCCONF=/dev/null TB --- 2012-02-11 06:52:50 - TARGET=arm TB --- 2012-02-11 06:52:50 - TARGET_ARCH=arm TB --- 2012-02-11 06:52:50 - TZ=UTC TB --- 2012-02-11 06:52:50 - __MAKE_CONF=/dev/null TB --- 2012-02-11 06:52:50 - cd /src TB --- 2012-02-11 06:52:50 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Sat Feb 11 06:52:50 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Sat Feb 11 06:55:19 UTC 2012 TB --- 2012-02-11 06:55:19 - cd /src/sys/arm/conf TB --- 2012-02-11 06:55:19 - /usr/sbin/config -m CRB TB --- 2012-02-11 06:55:19 - building CRB kernel TB --- 2012-02-11 06:55:19 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 06:55:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 06:55:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 06:55:19 - SRCCONF=/dev/null TB --- 2012-02-11 06:55:19 - TARGET=arm TB --- 2012-02-11 06:55:19 - TARGET_ARCH=arm TB --- 2012-02-11 06:55:19 - TZ=UTC TB --- 2012-02-11 06:55:19 - __MAKE_CONF=/dev/null TB --- 2012-02-11 06:55:19 - cd /src TB --- 2012-02-11 06:55:19 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Sat Feb 11 06:55:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CRB completed on Sat Feb 11 06:59:09 UTC 2012 TB --- 2012-02-11 06:59:09 - cd /src/sys/arm/conf TB --- 2012-02-11 06:59:09 - /usr/sbin/config -m DB-78XXX TB --- 2012-02-11 06:59:09 - building DB-78XXX kernel TB --- 2012-02-11 06:59:09 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 06:59:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 06:59:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 06:59:09 - SRCCONF=/dev/null TB --- 2012-02-11 06:59:09 - TARGET=arm TB --- 2012-02-11 06:59:09 - TARGET_ARCH=arm TB --- 2012-02-11 06:59:09 - TZ=UTC TB --- 2012-02-11 06:59:09 - __MAKE_CONF=/dev/null TB --- 2012-02-11 06:59:09 - cd /src TB --- 2012-02-11 06:59:09 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Sat Feb 11 06:59:09 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Sat Feb 11 07:01:48 UTC 2012 TB --- 2012-02-11 07:01:48 - cd /src/sys/arm/conf TB --- 2012-02-11 07:01:48 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-02-11 07:01:48 - building DB-88F5XXX kernel TB --- 2012-02-11 07:01:48 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 07:01:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 07:01:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 07:01:48 - SRCCONF=/dev/null TB --- 2012-02-11 07:01:48 - TARGET=arm TB --- 2012-02-11 07:01:48 - TARGET_ARCH=arm TB --- 2012-02-11 07:01:48 - TZ=UTC TB --- 2012-02-11 07:01:48 - __MAKE_CONF=/dev/null TB --- 2012-02-11 07:01:48 - cd /src TB --- 2012-02-11 07:01:48 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Sat Feb 11 07:01:48 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Sat Feb 11 07:04:25 UTC 2012 TB --- 2012-02-11 07:04:25 - cd /src/sys/arm/conf TB --- 2012-02-11 07:04:25 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-02-11 07:04:25 - building DB-88F6XXX kernel TB --- 2012-02-11 07:04:25 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 07:04:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 07:04:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 07:04:25 - SRCCONF=/dev/null TB --- 2012-02-11 07:04:25 - TARGET=arm TB --- 2012-02-11 07:04:25 - TARGET_ARCH=arm TB --- 2012-02-11 07:04:25 - TZ=UTC TB --- 2012-02-11 07:04:25 - __MAKE_CONF=/dev/null TB --- 2012-02-11 07:04:25 - cd /src TB --- 2012-02-11 07:04:25 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Sat Feb 11 07:04:25 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Sat Feb 11 07:07:37 UTC 2012 TB --- 2012-02-11 07:07:37 - cd /src/sys/arm/conf TB --- 2012-02-11 07:07:37 - /usr/sbin/config -m DOCKSTAR TB --- 2012-02-11 07:07:37 - building DOCKSTAR kernel TB --- 2012-02-11 07:07:37 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 07:07:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 07:07:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 07:07:37 - SRCCONF=/dev/null TB --- 2012-02-11 07:07:37 - TARGET=arm TB --- 2012-02-11 07:07:37 - TARGET_ARCH=arm TB --- 2012-02-11 07:07:37 - TZ=UTC TB --- 2012-02-11 07:07:37 - __MAKE_CONF=/dev/null TB --- 2012-02-11 07:07:37 - cd /src TB --- 2012-02-11 07:07:37 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Sat Feb 11 07:07:37 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Sat Feb 11 07:10:09 UTC 2012 TB --- 2012-02-11 07:10:09 - cd /src/sys/arm/conf TB --- 2012-02-11 07:10:09 - /usr/sbin/config -m EP80219 TB --- 2012-02-11 07:10:09 - building EP80219 kernel TB --- 2012-02-11 07:10:09 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 07:10:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 07:10:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 07:10:09 - SRCCONF=/dev/null TB --- 2012-02-11 07:10:09 - TARGET=arm TB --- 2012-02-11 07:10:09 - TARGET_ARCH=arm TB --- 2012-02-11 07:10:09 - TZ=UTC TB --- 2012-02-11 07:10:09 - __MAKE_CONF=/dev/null TB --- 2012-02-11 07:10:09 - cd /src TB --- 2012-02-11 07:10:09 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Sat Feb 11 07:10:09 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EP80219 completed on Sat Feb 11 07:13:03 UTC 2012 TB --- 2012-02-11 07:13:03 - cd /src/sys/arm/conf TB --- 2012-02-11 07:13:03 - /usr/sbin/config -m GUMSTIX TB --- 2012-02-11 07:13:03 - building GUMSTIX kernel TB --- 2012-02-11 07:13:03 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 07:13:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 07:13:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 07:13:03 - SRCCONF=/dev/null TB --- 2012-02-11 07:13:03 - TARGET=arm TB --- 2012-02-11 07:13:03 - TARGET_ARCH=arm TB --- 2012-02-11 07:13:03 - TZ=UTC TB --- 2012-02-11 07:13:03 - __MAKE_CONF=/dev/null TB --- 2012-02-11 07:13:03 - cd /src TB --- 2012-02-11 07:13:03 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Sat Feb 11 07:13:03 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GUMSTIX completed on Sat Feb 11 07:15:22 UTC 2012 TB --- 2012-02-11 07:15:22 - cd /src/sys/arm/conf TB --- 2012-02-11 07:15:22 - /usr/sbin/config -m HL200 TB --- 2012-02-11 07:15:22 - building HL200 kernel TB --- 2012-02-11 07:15:22 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 07:15:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 07:15:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 07:15:22 - SRCCONF=/dev/null TB --- 2012-02-11 07:15:22 - TARGET=arm TB --- 2012-02-11 07:15:22 - TARGET_ARCH=arm TB --- 2012-02-11 07:15:22 - TZ=UTC TB --- 2012-02-11 07:15:22 - __MAKE_CONF=/dev/null TB --- 2012-02-11 07:15:22 - cd /src TB --- 2012-02-11 07:15:22 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Sat Feb 11 07:15:22 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for HL200 completed on Sat Feb 11 07:18:27 UTC 2012 TB --- 2012-02-11 07:18:27 - cd /src/sys/arm/conf TB --- 2012-02-11 07:18:27 - /usr/sbin/config -m HL201 TB --- 2012-02-11 07:18:27 - building HL201 kernel TB --- 2012-02-11 07:18:27 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 07:18:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 07:18:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 07:18:27 - SRCCONF=/dev/null TB --- 2012-02-11 07:18:27 - TARGET=arm TB --- 2012-02-11 07:18:27 - TARGET_ARCH=arm TB --- 2012-02-11 07:18:27 - TZ=UTC TB --- 2012-02-11 07:18:27 - __MAKE_CONF=/dev/null TB --- 2012-02-11 07:18:27 - cd /src TB --- 2012-02-11 07:18:27 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Sat Feb 11 07:18:27 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for HL201 completed on Sat Feb 11 07:20:39 UTC 2012 TB --- 2012-02-11 07:20:39 - cd /src/sys/arm/conf TB --- 2012-02-11 07:20:39 - /usr/sbin/config -m IQ31244 TB --- 2012-02-11 07:20:39 - building IQ31244 kernel TB --- 2012-02-11 07:20:39 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 07:20:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 07:20:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 07:20:39 - SRCCONF=/dev/null TB --- 2012-02-11 07:20:39 - TARGET=arm TB --- 2012-02-11 07:20:39 - TARGET_ARCH=arm TB --- 2012-02-11 07:20:39 - TZ=UTC TB --- 2012-02-11 07:20:39 - __MAKE_CONF=/dev/null TB --- 2012-02-11 07:20:39 - cd /src TB --- 2012-02-11 07:20:39 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Sat Feb 11 07:20:39 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for IQ31244 completed on Sat Feb 11 07:23:56 UTC 2012 TB --- 2012-02-11 07:23:56 - cd /src/sys/arm/conf TB --- 2012-02-11 07:23:56 - /usr/sbin/config -m KB920X TB --- 2012-02-11 07:23:56 - building KB920X kernel TB --- 2012-02-11 07:23:56 - CROSS_BUILD_TESTING=YES TB --- 2012-02-11 07:23:56 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-11 07:23:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-11 07:23:56 - SRCCONF=/dev/null TB --- 2012-02-11 07:23:56 - TARGET=arm TB --- 2012-02-11 07:23:56 - TARGET_ARCH=arm TB --- 2012-02-11 07:23:56 - TZ=UTC TB --- 2012-02-11 07:23:56 - __MAKE_CONF=/dev/null TB --- 2012-02-11 07:23:56 - cd /src TB --- 2012-02-11 07:23:56 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Sat Feb 11 07:23:56 UTC 2012 >>> 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 [...] ld -Bshareable -d -warn-common -o nullfs.ko.debug nullfs.kld objcopy --only-keep-debug nullfs.ko.debug nullfs.ko.symbols objcopy --strip-debug --add-gnu-debuglink=nullfs.ko.symbols nullfs.ko.debug nullfs.ko ===> oce (all) cc -O -pipe -DSMP -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/oce/../../dev/oce -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/oce/../../dev/oce/oce_if.c cc1: warnings being treated as errors /src/sys/modules/oce/../../dev/oce/oce_if.c: In function 'oce_attach_ifp': /src/sys/modules/oce/../../dev/oce/oce_if.c:1647: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/oce. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-11 07:32:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-11 07:32:30 - ERROR: failed to build KB920X kernel TB --- 2012-02-11 07:32:30 - 4779.16 user 950.74 system 6149.68 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full