From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 11:06:50 2009 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 7A9DF1065730 for ; Mon, 12 Oct 2009 11:06:50 +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 022328FC18 for ; Mon, 12 Oct 2009 11:06:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9CB6mqc036321 for ; Mon, 12 Oct 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9CB6mju036317 for freebsd-arm@FreeBSD.org; Mon, 12 Oct 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Oct 2009 11:06:48 GMT Message-Id: <200910121106.n9CB6mju036317@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, 12 Oct 2009 11:06:50 -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/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 11:15:44 2009 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 5AB011065696 for ; Mon, 12 Oct 2009 11:15:44 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 0BF4A8FC20 for ; Mon, 12 Oct 2009 11:15:43 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 1C23FC3BA4; Mon, 12 Oct 2009 13:10:03 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id 0InmkUTIoxPb; Mon, 12 Oct 2009 13:10:02 +0200 (CEST) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 48EB6C3BA9; Mon, 12 Oct 2009 13:10:02 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Rafal Jaworowski In-Reply-To: <200910081613.n98GDt7r053539@casselton.net> Date: Mon, 12 Oct 2009 13:15:41 +0200 Content-Transfer-Encoding: 7bit Message-Id: <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> References: <200910081613.n98GDt7r053539@casselton.net> To: Mark Tinguely X-Mailer: Apple Mail (2.1076) Cc: gballet@gmail.com, freebsd-arm@freebsd.org Subject: Re: Adding members to struct cpu_functions 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, 12 Oct 2009 11:15:44 -0000 On 2009-10-08, at 18:13, Mark Tinguely wrote: > -- on a tangent about the future -- > Since the ARMv7 is coming to FreeBSD, there are other ARMv4/5 vrs > ARMv6/7 > questions, the most important is should we break the new ARM chips > with > their physical tagged caches to another subbranch or define it into > the > existing code? One example of the existing pmap code that does not > mesh > well with ARMv6/7 is the exisiting flush of the level 2 cache > because the > old archs have VIVT level 2 caches). ARMv6/7 level 2 caches are PIPT, > and would not be flushed until DMA time. A simple solution would be if > an arch needs to flush the level 2 cache when it flushes the level 1 > cache, then it should do so in the level 1 cache flushing routine. I was wondering whether a separate pmap module for ARMv6-7 would not be the best approach. After all v6-7 should be considered an entirely new architecture variation, and we would avoid the very likely #ifdefs hell in case of a single pmap.c. Rafal From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 11:36:36 2009 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 E7F48106568B for ; Mon, 12 Oct 2009 11:36:36 +0000 (UTC) (envelope-from stas@deglitch.com) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id E14AE8FC13 for ; Mon, 12 Oct 2009 11:36:35 +0000 (UTC) Received: from stasss.yandex.ru (dhcp170-227-red.yandex.net [95.108.170.227]) by mx0.deglitch.com (Postfix) with ESMTPSA id 6316A8FC45; Mon, 12 Oct 2009 15:36:33 +0400 (MSD) Date: Mon, 12 Oct 2009 15:36:28 +0400 From: Stanislav Sedov To: Rafal Jaworowski Message-Id: <20091012153628.9196951f.stas@deglitch.com> In-Reply-To: <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> Organization: Deglitch Networks X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__12_Oct_2009_15_36_28_+0400_76ge5vAWbE9fDut7" Cc: gballet@gmail.com, Mark Tinguely , freebsd-arm@freebsd.org Subject: Re: Adding members to struct cpu_functions 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, 12 Oct 2009 11:36:37 -0000 --Signature=_Mon__12_Oct_2009_15_36_28_+0400_76ge5vAWbE9fDut7 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 12 Oct 2009 13:15:41 +0200 Rafal Jaworowski mentioned: >=20 > On 2009-10-08, at 18:13, Mark Tinguely wrote: >=20 > > -- on a tangent about the future -- > > Since the ARMv7 is coming to FreeBSD, there are other ARMv4/5 vrs =20 > > ARMv6/7 > > questions, the most important is should we break the new ARM chips =20 > > with > > their physical tagged caches to another subbranch or define it into =20 > > the > > existing code? One example of the existing pmap code that does not =20 > > mesh > > well with ARMv6/7 is the exisiting flush of the level 2 cache =20 > > because the > > old archs have VIVT level 2 caches). ARMv6/7 level 2 caches are PIPT, > > and would not be flushed until DMA time. A simple solution would be if > > an arch needs to flush the level 2 cache when it flushes the level 1 > > cache, then it should do so in the level 1 cache flushing routine. >=20 > I was wondering whether a separate pmap module for ARMv6-7 would not =20 > be the best approach. After all v6-7 should be considered an entirely =20 > new architecture variation, and we would avoid the very likely #ifdefs =20 > hell in case of a single pmap.c. >=20 Yeah, I think that would be the best solution. We could conditionally select the right pmap.c file based on the target CPU selected (just like we do for board variations for at91/marvell). --=20 Stanislav Sedov ST4096-RIPE --Signature=_Mon__12_Oct_2009_15_36_28_+0400_76ge5vAWbE9fDut7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJK0xTAAAoJEKN82nOYvCd0z3AP/0MBYNgRt4Gz4vCo2j+JZHIY L60R2hai88fAbG/5mBfQWP/rGUCUz0FFU/is8g9Vgajx2uJzy7mbhBgs16IEvlO9 LRETjDoJy+NHYq1u5te9tvgr2v13kiZkmLIyuKdSk4o8Umcrc/Q9H46jliItNbY/ jNAbfK1gCOM4hEGCpclACzjBXj/P7RQJ/DCiawNYl49T2kYx/mwUsxJudQheJZ/w h5DCh3bMahjA05tzf+GhUiFPc+M6znWIubN/RY3mGgZFpv5JrE43TEEnAkBIVCB/ Bc62B4BSY0GIJwvqF/wmpoLrqFc2DCIL7NoKo9z5GfYIfletB6Ss3UpRldZxIBlZ uQ8cMqLBJ003ZTjqLDseaydDSmb/g64A4z98643AGBcK/UfxvxDu++psHD5+i7Af 0dxzCZ4UZ/hAHEmc3t4OOhwLc8Tjx3YjPXM+asWayJMdU0Z01CL6eebiGUqXeTGr b4/Sl9qefGSJAbYWaK91pyia8HjwNMB0GUA8sekAXrJ8zGUP9lpPZUiMS7aFjc97 NeWNEHJMNyZs2VB/5UoOt7VfjZumFAtNQeaefiHP/DkyDlwxQlRdmoYnIIVe0Q8n hmoE1o2FPt7Nep0F9gTBBwCprjbINlA5gBsCgAS3U4Q6Hm4eaGuT6mh220+VaG/D NRuAtK7kbTqZvXLFNR8X =atIn -----END PGP SIGNATURE----- --Signature=_Mon__12_Oct_2009_15_36_28_+0400_76ge5vAWbE9fDut7-- From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 12:29:21 2009 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 6CD7E1065693 for ; Mon, 12 Oct 2009 12:29:21 +0000 (UTC) (envelope-from gballet@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id EC40B8FC14 for ; Mon, 12 Oct 2009 12:29:19 +0000 (UTC) Received: by ewy18 with SMTP id 18so2772271ewy.43 for ; Mon, 12 Oct 2009 05:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jWV1MN+d3mw9ZunglJwb4XUA4ls/mbUsXiVqYDaU3HU=; b=m1vw/m6oanKVzPNRZA/TvafTlaGzDga/wiigWkC7SIcfN6MvHhYIH+YWfReF+Dr2e6 Fe7wQyaonU4rDarJI0TO+/B0i+FBUPmFbDfNbkFRWacR4HYNfBnhzFADBGv4VG9/MtLi AV+sW6wEUBmcExd++C0kL2MrQkay4NeaWJhyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=L4xnzu5Rr0a8NWJeY0ieOjmYn6asJ8SOpWRQuhRmsKB2etTOjTCbGqIjDrWhAES8DM HVxgY+jjlSafCffGWwHbEaTmVMHAoMg3Bug2aYJx1yoHYJeN+d5dng8a4dpy4H5ATPtf yHC/FDndESJUGh6E00DWvRWGX/JorcvNVXuIc= MIME-Version: 1.0 Received: by 10.211.160.19 with SMTP id m19mr2713903ebo.50.1255350559040; Mon, 12 Oct 2009 05:29:19 -0700 (PDT) In-Reply-To: <20091012153628.9196951f.stas@deglitch.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> Date: Mon, 12 Oct 2009 14:29:19 +0200 Message-ID: From: Guillaume Ballet To: Stanislav Sedov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mark Tinguely , freebsd-arm@freebsd.org Subject: Re: Adding members to struct cpu_functions 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, 12 Oct 2009 12:29:21 -0000 On Mon, Oct 12, 2009 at 1:36 PM, Stanislav Sedov wrote: > On Mon, 12 Oct 2009 13:15:41 +0200 > Rafal Jaworowski mentioned: > >> >> On 2009-10-08, at 18:13, Mark Tinguely wrote: >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- on a tangent about the futu= re -- >> > Since the ARMv7 is coming to FreeBSD, there are other ARMv4/5 vrs >> > ARMv6/7 >> > questions, the most important is should we break the new ARM chips >> > with >> > their physical tagged caches to another subbranch or define it into >> > the >> > existing code? One example of the existing pmap code that does not >> > mesh >> > well with ARMv6/7 is the exisiting flush of the level 2 cache >> > because the >> > old archs have VIVT level 2 caches). ARMv6/7 level 2 caches are PIPT, >> > and would not be flushed until DMA time. A simple solution would be if >> > an arch needs to flush the level 2 cache when it flushes the level 1 >> > cache, then it should do so in the level 1 cache flushing routine. >> >> I was wondering whether a separate pmap module for ARMv6-7 would not >> be the best approach. After all v6-7 should be considered an entirely >> new architecture variation, and we would avoid the very likely #ifdefs >> hell in case of a single pmap.c. >> > > Yeah, I think that would be the best solution. =A0We could conditionally > select the right pmap.c file based on the target CPU selected (just > like we do for board variations for at91/marvell). > pmap.c is a very large file that seems to change very often. I fear having several versions is going to be difficult to maintain. Granted, I haven't read the whole file line after line. Yet it seems to me its content can be abstracted to rely on arch-specific functions that would be found in cpufuncs instead of hardcoded macros. Is there something fundamentally wrong with enhancing struct cpufunc in order to let the portmeisters decide what the MMU and caching bits should look like? This is a blocking issue for me, since it looks like the omap has some problem with backward compatibility mode. Without fixing up the TLBs in my initarm function, it doesn't work. Speaking of #ifdef hell, why not breaking cpufuncs.c into several cpufuncs_.c? That would be a good way to start that reorganization Mark has been talking about in his email. Guillaume From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 14:22:01 2009 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 C9C9C106568B for ; Mon, 12 Oct 2009 14:22:01 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 99D228FC1A for ; Mon, 12 Oct 2009 14:22:01 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7.0-5.01 32bit (built Feb 19 2009)) id <0KRE00F02L4P1P00@smtpauth1.wiscmail.wisc.edu> for freebsd-arm@freebsd.org; Mon, 12 Oct 2009 08:22:01 -0500 (CDT) Received: from comporellon.tachypleus.net (adsl-75-50-88-75.dsl.mdsnwi.sbcglobal.net [75.50.88.75]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7.0-5.01 32bit (built Feb 19 2009)) with ESMTPSA id <0KRE003O7L4N3B40@smtpauth1.wiscmail.wisc.edu>; Mon, 12 Oct 2009 08:22:00 -0500 (CDT) Date: Mon, 12 Oct 2009 08:21:58 -0500 From: Nathan Whitehorn In-reply-to: To: Guillaume Ballet Message-id: <4AD32D76.3090401@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=75.50.88.75 X-Spam-PmxInfo: Server=avs-14, Version=5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2009.10.12.131217, SenderIP=75.50.88.75 References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090905) Cc: Mark Tinguely , freebsd-arm@freebsd.org, Stanislav Sedov Subject: Re: Adding members to struct cpu_functions 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, 12 Oct 2009 14:22:02 -0000 Guillaume Ballet wrote: > On Mon, Oct 12, 2009 at 1:36 PM, Stanislav Sedov wrote: > >> On Mon, 12 Oct 2009 13:15:41 +0200 >> Rafal Jaworowski mentioned: >> >> >>> On 2009-10-08, at 18:13, Mark Tinguely wrote: >>> >>> >>>> -- on a tangent about the future -- >>>> Since the ARMv7 is coming to FreeBSD, there are other ARMv4/5 vrs >>>> ARMv6/7 >>>> questions, the most important is should we break the new ARM chips >>>> with >>>> their physical tagged caches to another subbranch or define it into >>>> the >>>> existing code? One example of the existing pmap code that does not >>>> mesh >>>> well with ARMv6/7 is the exisiting flush of the level 2 cache >>>> because the >>>> old archs have VIVT level 2 caches). ARMv6/7 level 2 caches are PIPT, >>>> and would not be flushed until DMA time. A simple solution would be if >>>> an arch needs to flush the level 2 cache when it flushes the level 1 >>>> cache, then it should do so in the level 1 cache flushing routine. >>>> >>> I was wondering whether a separate pmap module for ARMv6-7 would not >>> be the best approach. After all v6-7 should be considered an entirely >>> new architecture variation, and we would avoid the very likely #ifdefs >>> hell in case of a single pmap.c. >>> >>> >> Yeah, I think that would be the best solution. We could conditionally >> select the right pmap.c file based on the target CPU selected (just >> like we do for board variations for at91/marvell). >> >> > > pmap.c is a very large file that seems to change very often. I fear > having several versions is going to be difficult to maintain. Granted, > I haven't read the whole file line after line. Yet it seems to me its > content can be abstracted to rely on arch-specific functions that > would be found in cpufuncs instead of hardcoded macros. Is there > something fundamentally wrong with enhancing struct cpufunc in order > to let the portmeisters decide what the MMU and caching bits should > look like? This is a blocking issue for me, since it looks like the > omap has some problem with backward compatibility mode. Without fixing > up the TLBs in my initarm function, it doesn't work. > > Speaking of #ifdef hell, why not breaking cpufuncs.c into several > cpufuncs_.c? That would be a good way to start that > reorganization Mark has been talking about in his email. > One thing that might be worth looking at while thinking about this is how this is done on PowerPC. We have run-time selectable PMAP modules using KOBJ to handle CPUs with different MMU designs, as well as a platform module scheme, again using KOBJ, to pick the appropriate PMAP for the board as well as determine the physical memory layout and such things. One of the nice things about the approach is that it is easy to subclass if you have a new, marginally different, design, and it avoids #ifdef hell as well as letting you build a GENERIC kernel with support for multiple MMU designs and board types (the last less of a concern on ARM, though). -Nathan From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 15:07:37 2009 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 E82A91065670; Mon, 12 Oct 2009 15:07:36 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 8EB828FC20; Mon, 12 Oct 2009 15:07:36 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id F182FC3BA8; Mon, 12 Oct 2009 17:01:55 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id jfVQxQ84+vdg; Mon, 12 Oct 2009 17:01:54 +0200 (CEST) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 0CEA5C3BA4; Mon, 12 Oct 2009 17:01:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Rafal Jaworowski In-Reply-To: <4AD32D76.3090401@freebsd.org> Date: Mon, 12 Oct 2009 17:07:33 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <4AD32D76.3090401@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1076) Cc: Guillaume Ballet , Mark Tinguely , freebsd-arm@freebsd.org, Stanislav Sedov Subject: Re: Adding members to struct cpu_functions 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, 12 Oct 2009 15:07:37 -0000 On 2009-10-12, at 15:21, Nathan Whitehorn wrote: >>>> I was wondering whether a separate pmap module for ARMv6-7 would >>>> not >>>> be the best approach. After all v6-7 should be considered an >>>> entirely >>>> new architecture variation, and we would avoid the very likely >>>> #ifdefs >>>> hell in case of a single pmap.c. >>>> >>>> >>> Yeah, I think that would be the best solution. We could >>> conditionally >>> select the right pmap.c file based on the target CPU selected (just >>> like we do for board variations for at91/marvell). >>> >>> >> >> pmap.c is a very large file that seems to change very often. I fear >> having several versions is going to be difficult to maintain. >> Granted, >> I haven't read the whole file line after line. Yet it seems to me its >> content can be abstracted to rely on arch-specific functions that >> would be found in cpufuncs instead of hardcoded macros. Is there >> something fundamentally wrong with enhancing struct cpufunc in order >> to let the portmeisters decide what the MMU and caching bits should >> look like? This is a blocking issue for me, since it looks like the >> omap has some problem with backward compatibility mode. Without >> fixing >> up the TLBs in my initarm function, it doesn't work. >> >> Speaking of #ifdef hell, why not breaking cpufuncs.c into several >> cpufuncs_.c? That would be a good way to start that >> reorganization Mark has been talking about in his email. >> > One thing that might be worth looking at while thinking about this > is how this is done on PowerPC. We have run-time selectable PMAP > modules using KOBJ to handle CPUs with different MMU designs, as > well as a platform module scheme, again using KOBJ, to pick the > appropriate PMAP for the board as well as determine the physical > memory layout and such things. One of the nice things about the > approach is that it is easy to subclass if you have a new, > marginally different, design, and it avoids #ifdef hell as well as > letting you build a GENERIC kernel with support for multiple MMU > designs and board types (the last less of a concern on ARM, though). What always concerned me was the performance cost this imposes, and it would be a really useful exercise to measure what is the actual impact of KOBJ-tized pmap we have in PowerPC; with an often-called interface like pmap it might occur the penalty is not that little.. Rafal From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 20:35:28 2009 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 B7F0C106566B for ; Mon, 12 Oct 2009 20:35:28 +0000 (UTC) (envelope-from gballet@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 143CE8FC16 for ; Mon, 12 Oct 2009 20:35:27 +0000 (UTC) Received: by ewy18 with SMTP id 18so3136814ewy.43 for ; Mon, 12 Oct 2009 13:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Roe4tf6SU0V6pi65/YZe5k/B++ptG1SUWAY8m62lwv8=; b=Ve0PnkTpSJGeUIk3UkeILQtQhcz1+ficf8vTR5e97gT+p/PufJ4ztsD93TyFX1Nz8W LhSGluI2bqjGyp2mHPp+LehpwHrUojZpvojK/9YASpK3hki5KbQ3KrQvxDSyhDRgKYBS 1kk1s+qK5hE/rwpz/mX0Hber9mE/UWoWOzdEA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=beeZJSXeOpg0qRMfV6XjeaKpc6DWIckpmgMyX0PT+Sx9Uiey62yInsQjCQZyuVoE22 aDMCdEx2cBv6WB4VBe1HyIp3IE0MzIdPmOnFHml5Fw6nfEOt090Wt17Q+Tz4/t57IKFN Z2kvgHWSCIgC+R1+FdscKOfJfap8s2mAxy05o= MIME-Version: 1.0 Received: by 10.210.84.10 with SMTP id h10mr4434040ebb.70.1255379726975; Mon, 12 Oct 2009 13:35:26 -0700 (PDT) In-Reply-To: <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <4AD32D76.3090401@freebsd.org> <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> Date: Mon, 12 Oct 2009 22:35:26 +0200 Message-ID: From: Guillaume Ballet To: Nathan Whitehorn , Mark Tinguely , freebsd-arm@freebsd.org, Stanislav Sedov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Adding members to struct cpu_functions 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, 12 Oct 2009 20:35:28 -0000 On Mon, Oct 12, 2009 at 5:07 PM, Rafal Jaworowski wrote: > > On 2009-10-12, at 15:21, Nathan Whitehorn wrote: > >>>>> I was wondering whether a separate pmap module for ARMv6-7 would not >>>>> be the best approach. After all v6-7 should be considered an entirely >>>>> new architecture variation, and we would avoid the very likely #ifdef= s >>>>> hell in case of a single pmap.c. >>>>> >>>>> >>>> Yeah, I think that would be the best solution. =A0We could conditional= ly >>>> select the right pmap.c file based on the target CPU selected (just >>>> like we do for board variations for at91/marvell). >>>> >>>> >>> >>> pmap.c is a very large file that seems to change very often. I fear >>> having several versions is going to be difficult to maintain. Granted, >>> I haven't read the whole file line after line. Yet it seems to me its >>> content can be abstracted to rely on arch-specific functions that >>> would be found in cpufuncs instead of hardcoded macros. Is there >>> something fundamentally wrong with enhancing struct cpufunc in order >>> to let the portmeisters decide what the MMU and caching bits should >>> look like? This is a blocking issue for me, since it looks like the >>> omap has some problem with backward compatibility mode. Without fixing >>> up the TLBs in my initarm function, it doesn't work. >>> >>> Speaking of #ifdef hell, why not breaking cpufuncs.c into several >>> cpufuncs_.c? That would be a good way to start that >>> reorganization Mark has been talking about in his email. >>> >> One thing that might be worth looking at while thinking about this is ho= w >> this is done on PowerPC. We have run-time selectable PMAP modules using = KOBJ >> to handle CPUs with different MMU designs, as well as a platform module >> scheme, again using KOBJ, to pick the appropriate PMAP for the board as = well >> as determine the physical memory layout and such things. One of the nice >> things about the approach is that it is easy to subclass if you have a n= ew, >> marginally different, design, and it avoids #ifdef hell as well as letti= ng >> you build a GENERIC kernel with support for multiple MMU designs and boa= rd >> types (the last less of a concern on ARM, though). > > What always concerned me was the performance cost this imposes, and it wo= uld > be a really useful exercise to measure what is the actual impact of > KOBJ-tized pmap we have in PowerPC; with an often-called interface like p= map > it might occur the penalty is not that little.. > > Rafal > > Good point. Using KOBJs this way is really cool, but the overhead is going to be a concern if it is used by an application that allocates memory very often. This is not the case of most embedded appliances I worked with, still one should not assume anything about the userland at kernel level. As a result, extending the struct cpu_functions is not a good thing either, for the same reason. The compiler can not inline a call through a function pointer. In which case, why not create a bunch of headers files with the pattern cpufunc_myarch.h, in which all functions would be declared inline? Something like: static inline l2_l_entry(vm_addr_t pa, int prot, int cache); static inline l2_s_entry(vm_addr_t pa, int prot, int cache); ... which would then be included by pmap.c and friends. One problem is that such a change affects all platforms at the same time, and therefore requires all portmeisters to implement the functions that are needed. That should not be too difficult, though, because so far it was the same macros that were used by all platforms. Another problem is that it requires some build script magic to make sure the correct header is included depending on the arch. I wonder if this is easy? Guillaume From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 20:46:22 2009 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 6AF331065676 for ; Mon, 12 Oct 2009 20:46:22 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 2F9368FC0A for ; Mon, 12 Oct 2009 20:46:22 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 29597489EE for ; Mon, 12 Oct 2009 21:46:21 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn8Y-HMuFbAb for ; Mon, 12 Oct 2009 21:46:17 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 05CAE489EB for ; Mon, 12 Oct 2009 21:46:16 +0100 (BST) Message-ID: <4AD39573.2060403@tomjudge.com> Date: Mon, 12 Oct 2009 20:45:39 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: i80321 PCI Memory Allocations Fix 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, 12 Oct 2009 20:46:22 -0000 Hi, While I was porting FreeBSD to my Intel SS4000-E NAS unit I came across what seems a bug in the PCI memory allocation routings for the i80321. Here is the patch that I have used to fix the issue: http://svn.tomjudge.com/freebsd/patches/ss4000-e/i80321_pci.patch Does this seem correct (functionally it seems to work ok for me)? Thanks PS: Anyone interested can track my project progress here: http://www.tomjudge.com/index.php/SS4000-E From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 21:29:25 2009 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 39154106568D for ; Mon, 12 Oct 2009 21:29:25 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id D2CAE8FC20 for ; Mon, 12 Oct 2009 21:29:24 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n9CLTHwX087997; Mon, 12 Oct 2009 16:29:17 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1255382957; bh=QugtbOQervTwVkdu2+8SdEUj1v2fwR6K3Dg4KgPGOJo=; h=Date:From:Message-Id:To:Subject:In-Reply-To; b=XLvFJ+oP2H6gO0QYOhPvFBz2FQhcSs9LGREE+tg1LTs2G/XV5DznTaUpMbmxcLmx4 cgi6pM4bcBK5sL+qDCXzUmc6QBvE8sLOAxX3Rdf+cs69uld6oE9pfkSikuo1CRtNn0 ElJFpHiKdc8D7GZrxwNiyoNvENeGi9NmMmLae0yY= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n9CLTHsp087996; Mon, 12 Oct 2009 16:29:17 -0500 (CDT) (envelope-from tinguely) Date: Mon, 12 Oct 2009 16:29:17 -0500 (CDT) From: Mark Tinguely Message-Id: <200910122129.n9CLTHsp087996@casselton.net> To: freebsd-arm@freebsd.org, gballet@gmail.com, nwhitehorn@freebsd.org, stas@deglitch.com, tinguely@casselton.net In-Reply-To: Cc: Subject: Re: Adding members to struct cpu_functions 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, 12 Oct 2009 21:29:25 -0000 > As a result, extending the struct cpu_functions is not a good thing > either, for the same reason. The compiler can not inline a call > through a function pointer. > > In which case, why not create a bunch of headers files with the > pattern cpufunc_myarch.h, in which all functions would be declared > inline? Something like: > > static inline l2_l_entry(vm_addr_t pa, int prot, int cache); > static inline l2_s_entry(vm_addr_t pa, int prot, int cache); > ... > which would then be included by pmap.c and friends. I think they need to be regular function calls because assembly routines call the per-cpu functions. A few simple macros would save the branch to NOP functions. > One problem is that such a change affects all platforms at the same > time, and therefore requires all portmeisters to implement the > functions that are needed. That should not be too difficult, though, > because so far it was the same macros that were used by all platforms. > Another problem is that it requires some build script magic to make > sure the correct header is included depending on the arch. I wonder if > this is easy? --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 21:47:19 2009 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 D1770106566B for ; Mon, 12 Oct 2009 21:47:19 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 9214E8FC17 for ; Mon, 12 Oct 2009 21:47:19 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 7F8C6582A9; Mon, 12 Oct 2009 16:15:37 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id HL+df+VfQ+Qt; Mon, 12 Oct 2009 16:15:37 -0500 (CDT) Received: from wanderer.tachypleus.net (i3-dhcp-172-16-55-200.icecube.wisc.edu [172.16.55.200]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 4186F582A8; Mon, 12 Oct 2009 16:15:37 -0500 (CDT) Message-ID: <4AD39C78.5050309@freebsd.org> Date: Mon, 12 Oct 2009 16:15:36 -0500 From: Nathan Whitehorn User-Agent: Thunderbird 2.0.0.23 (X11/20090909) MIME-Version: 1.0 To: Rafal Jaworowski References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <4AD32D76.3090401@freebsd.org> <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> In-Reply-To: <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Guillaume Ballet , Mark Tinguely , freebsd-arm@freebsd.org, Stanislav Sedov Subject: Re: Adding members to struct cpu_functions 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, 12 Oct 2009 21:47:20 -0000 Rafal Jaworowski wrote: > > On 2009-10-12, at 15:21, Nathan Whitehorn wrote: > >>>>> I was wondering whether a separate pmap module for ARMv6-7 would not >>>>> be the best approach. After all v6-7 should be considered an entirely >>>>> new architecture variation, and we would avoid the very likely >>>>> #ifdefs >>>>> hell in case of a single pmap.c. >>>>> >>>>> >>>> Yeah, I think that would be the best solution. We could conditionally >>>> select the right pmap.c file based on the target CPU selected (just >>>> like we do for board variations for at91/marvell). >>>> >>>> >>> >>> pmap.c is a very large file that seems to change very often. I fear >>> having several versions is going to be difficult to maintain. Granted, >>> I haven't read the whole file line after line. Yet it seems to me its >>> content can be abstracted to rely on arch-specific functions that >>> would be found in cpufuncs instead of hardcoded macros. Is there >>> something fundamentally wrong with enhancing struct cpufunc in order >>> to let the portmeisters decide what the MMU and caching bits should >>> look like? This is a blocking issue for me, since it looks like the >>> omap has some problem with backward compatibility mode. Without fixing >>> up the TLBs in my initarm function, it doesn't work. >>> >>> Speaking of #ifdef hell, why not breaking cpufuncs.c into several >>> cpufuncs_.c? That would be a good way to start that >>> reorganization Mark has been talking about in his email. >>> >> One thing that might be worth looking at while thinking about this is >> how this is done on PowerPC. We have run-time selectable PMAP modules >> using KOBJ to handle CPUs with different MMU designs, as well as a >> platform module scheme, again using KOBJ, to pick the appropriate >> PMAP for the board as well as determine the physical memory layout >> and such things. One of the nice things about the approach is that it >> is easy to subclass if you have a new, marginally different, design, >> and it avoids #ifdef hell as well as letting you build a GENERIC >> kernel with support for multiple MMU designs and board types (the >> last less of a concern on ARM, though). > > What always concerned me was the performance cost this imposes, and it > would be a really useful exercise to measure what is the actual impact > of KOBJ-tized pmap we have in PowerPC; with an often-called interface > like pmap it might occur the penalty is not that little.. Using the KOBJ cache means that it is only marginally more expensive than a standard function pointer call. There's a 9-year-old note in the commit log for sys/sys/kobj.h that it takes about 30% longer to call a function that does nothing via KOBJ versus a direct call on a 300 MHz P2 (a 10 ns time difference). Given that and that pmap methods do, in fact, do things besides get called and immediately return, I suspect non-KOBJ related execution time will dwarf any time loss from the indirection. I'll try to repeat the measurement in the next few days, however, since this is important to know. -Nathan From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 23:44:47 2009 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 04DE11065672; Mon, 12 Oct 2009 23:44:47 +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 BA5C58FC22; Mon, 12 Oct 2009 23:44:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n9CNijju037646; Mon, 12 Oct 2009 19:44:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n9CNijv9037645; Mon, 12 Oct 2009 23:44:45 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 12 Oct 2009 23:44:45 GMT Message-Id: <200910122344.n9CNijv9037645@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: Mon, 12 Oct 2009 23:44:47 -0000 TB --- 2009-10-12 23:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 23:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-10-12 23:30:00 - cleaning the object tree TB --- 2009-10-12 23:30:11 - cvsupping the source tree TB --- 2009-10-12 23:30:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2009-10-12 23:30:42 - building world TB --- 2009-10-12 23:30:42 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 23:30:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 23:30:42 - TARGET=arm TB --- 2009-10-12 23:30:42 - TARGET_ARCH=arm TB --- 2009-10-12 23:30:42 - TZ=UTC TB --- 2009-10-12 23:30:42 - __MAKE_CONF=/dev/null TB --- 2009-10-12 23:30:42 - cd /src TB --- 2009-10-12 23:30:42 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 23:30:42 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -fpic -DPIC -O -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/arm/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 23:44:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 23:44:45 - ERROR: failed to build world TB --- 2009-10-12 23:44:45 - 645.96 user 159.28 system 885.73 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Oct 13 00:43:04 2009 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 C636C106568F; Tue, 13 Oct 2009 00:43:04 +0000 (UTC) (envelope-from franson@gmail.com) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by mx1.freebsd.org (Postfix) with ESMTP id 6FF728FC1A; Tue, 13 Oct 2009 00:43:04 +0000 (UTC) Received: by iwn27 with SMTP id 27so4750722iwn.7 for ; Mon, 12 Oct 2009 17:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=GbigGXlKR8qqZz0vxufZFx/DJeFhIjRb4gW+LNjZTLA=; b=ZnW3Px+MLbjgHJLUsBblsuB4ajYxRaP2ZVX5LHsuKtvf0tzyiBYRkOxD7hJwn15FEA aNs3J+bLDvA2hVy3h5pMeDoPEYlzd9jZWQTW8QgEWTZVIFRy6kZHuGs5czxKJyQLMHW/ VwyzsxcS4P82TAYrbWuo9lT4O1PxHlYohWhu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hOqSDP7PvkhuPTgy/r98ivgwIqZoXZ+zZb7Gmv+k1bSgfZIx6IGHQNyWI5qCDLOPyN IkY1duFFZ5cHqydFvqNWtr8JFHOl4Cxz/Mm8pt1xfJjGTTIY2QOq+BFx4pWVZKREctNu 624KaEh6R/hilVzRN5XgPpvaCmOAijELAi8yU= MIME-Version: 1.0 Sender: franson@gmail.com Received: by 10.231.121.93 with SMTP id g29mr9842738ibr.13.1255393147008; Mon, 12 Oct 2009 17:19:07 -0700 (PDT) In-Reply-To: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> Date: Tue, 13 Oct 2009 08:19:06 +0800 X-Google-Sender-Auth: b1d7dfc81ac29ac4 Message-ID: From: quickembed To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm 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, 13 Oct 2009 00:43:04 -0000 this error shows you have not indicate how to compile libgssapi.a file. CC is for .c file, you need to tell what's for .a (assembly) file. On Tue, Oct 13, 2009 at 7:44 AM, FreeBSD Tinderbox wrote: > TB --- 2009-10-12 23:30:00 - tinderbox 2.6 running on freebsd-current.sen= tex.ca > TB --- 2009-10-12 23:30:00 - starting HEAD tinderbox run for arm/arm > TB --- 2009-10-12 23:30:00 - cleaning the object tree > TB --- 2009-10-12 23:30:11 - cvsupping the source tree > TB --- 2009-10-12 23:30:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sente= x.ca /tinderbox/HEAD/arm/arm/supfile > TB --- 2009-10-12 23:30:42 - building world > TB --- 2009-10-12 23:30:42 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2009-10-12 23:30:42 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-10-12 23:30:42 - TARGET=3Darm > TB --- 2009-10-12 23:30:42 - TARGET_ARCH=3Darm > TB --- 2009-10-12 23:30:42 - TZ=3DUTC > TB --- 2009-10-12 23:30:42 - __MAKE_CONF=3D/dev/null > TB --- 2009-10-12 23:30:42 - cd /src > TB --- 2009-10-12 23:30:42 - /usr/bin/make -B buildworld >>>> World build started on Mon Oct 12 23:30:42 UTC 2009 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries > [...] > cc -fpic -DPIC -O -pipe =A0-I/src/kerberos5/lib/libgssapi_krb5/../../../c= rypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypt= o/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../cryp= to/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/hei= mdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/l= ib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../incl= ude -std=3Dgnu99 =A0-c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/he= imdal/lib/gssapi/krb5/wrap.c -o wrap.So > cc -fpic -DPIC -O -pipe =A0-I/src/kerberos5/lib/libgssapi_krb5/../../../c= rypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypt= o/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../cryp= to/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/hei= mdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/l= ib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../incl= ude -std=3Dgnu99 =A0-c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_= krb5.So > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extrac= t_authz_data_from_sec_context': > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit decla= ration of function 'der_get_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit decla= ration of function 'der_free_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit decla= ration of function 'der_length_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit decla= ration of function 'der_put_oid' > make: don't know how to make /obj/arm/src/tmp/usr/lib/libgssapi.a. Stop > *** Error code 2 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-10-12 23:44:45 - WARNING: /usr/bin/make returned exit code = =A01 > TB --- 2009-10-12 23:44:45 - ERROR: failed to build world > TB --- 2009-10-12 23:44:45 - 645.96 user 159.28 system 885.73 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full > _______________________________________________ > 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" > From owner-freebsd-arm@FreeBSD.ORG Tue Oct 13 04:09:39 2009 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 44661106568B; Tue, 13 Oct 2009 04:09:39 +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 046A98FC1E; Tue, 13 Oct 2009 04:09:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n9D49cjY060990; Tue, 13 Oct 2009 00:09:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n9D49c48060977; Tue, 13 Oct 2009 04:09:38 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 13 Oct 2009 04:09:38 GMT Message-Id: <200910130409.n9D49c48060977@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: Tue, 13 Oct 2009 04:09:39 -0000 TB --- 2009-10-13 03:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-13 03:55:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-10-13 03:55:00 - cleaning the object tree TB --- 2009-10-13 03:55:05 - cvsupping the source tree TB --- 2009-10-13 03:55:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2009-10-13 03:55:29 - building world TB --- 2009-10-13 03:55:29 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-13 03:55:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-13 03:55:29 - TARGET=arm TB --- 2009-10-13 03:55:29 - TARGET_ARCH=arm TB --- 2009-10-13 03:55:29 - TZ=UTC TB --- 2009-10-13 03:55:29 - __MAKE_CONF=/dev/null TB --- 2009-10-13 03:55:29 - cd /src TB --- 2009-10-13 03:55:29 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 13 03:55:29 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -fpic -DPIC -O -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/arm/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 04:09:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 04:09:38 - ERROR: failed to build world TB --- 2009-10-13 04:09:38 - 644.73 user 158.41 system 878.05 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Oct 13 18:50:57 2009 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 D6309106566B for ; Tue, 13 Oct 2009 18:50:57 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 90CA88FC1E for ; Tue, 13 Oct 2009 18:50:57 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 228616D41B; Tue, 13 Oct 2009 18:32:37 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id CF1C784503; Tue, 13 Oct 2009 20:32:36 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: quickembed References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> Date: Tue, 13 Oct 2009 20:32:36 +0200 In-Reply-To: (quickembed@gmail.com's message of "Tue, 13 Oct 2009 08:19:06 +0800") Message-ID: <86vdijdu0r.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arm@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm 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, 13 Oct 2009 18:50:57 -0000 quickembed writes: > this error shows you have not indicate how to compile libgssapi.a file. > CC is for .c file, you need to tell what's for .a (assembly) file. No, the command line is correct. Assembler sources end in .s or .S; .a is a static library. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arm@FreeBSD.ORG Tue Oct 13 23:28:30 2009 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 8173C1065679; Tue, 13 Oct 2009 23:28:30 +0000 (UTC) (envelope-from franson@gmail.com) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC768FC46; Tue, 13 Oct 2009 23:28:29 +0000 (UTC) Received: by iwn27 with SMTP id 27so5286933iwn.7 for ; Tue, 13 Oct 2009 16:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=fRSL8vsrL4+Lq7b8XFkTNIc28SdJ0S0lTch1Gd5wTRI=; b=VnmX13Pgu8zzaW9q+21BPkfRup2rVP2D0o6dIqt0LIO/H3Ouz62tO2EurUlB52gHCl Ar0oVU0z8pLAg04hTf5zmiLaTfc32W61cJKTJBDYvrVN82tUDz7287OV51xFINC+wIY/ OKxOmxWOgiFGYL9KK6J5lcFIXzeANK4iVn9fU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=OUd4O8JVy8I2PchrBQtxBqIKRVVnrTMQhvd4PR03H2NqCwzHdfeEF18QZuTq8ldqop 9IJcUS9hdnfg0tvZWEMtD+kpYuouKYmfXXouOvUYdyQozqmSnsG+KdODMdKmzYlfTTOG 7wrG0wAzGxzAjyqr6go+avdJvT50E5EZZkJsM= MIME-Version: 1.0 Sender: franson@gmail.com Received: by 10.231.123.216 with SMTP id q24mr2390733ibr.43.1255476509349; Tue, 13 Oct 2009 16:28:29 -0700 (PDT) In-Reply-To: <86vdijdu0r.fsf@ds4.des.no> References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> Date: Wed, 14 Oct 2009 07:28:29 +0800 X-Google-Sender-Auth: 0711d74f432db147 Message-ID: From: quickembed To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arm@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm 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, 13 Oct 2009 23:28:30 -0000 Then it should be indicated how to "link". 2009/10/14 Dag-Erling Sm=F8rgrav : > quickembed writes: >> this error shows you have not indicate how to compile libgssapi.a file. >> CC is for .c file, you need to tell what's for .a (assembly) file. > > No, the command line is correct. =A0Assembler sources end in .s or .S; .a > is a static library. > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > From owner-freebsd-arm@FreeBSD.ORG Tue Oct 13 23:47:53 2009 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 C2E561065672; Tue, 13 Oct 2009 23:47:53 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 814248FC1D; Tue, 13 Oct 2009 23:47:53 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id A1B3A6D41B; Tue, 13 Oct 2009 23:47:52 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 3901384513; Wed, 14 Oct 2009 01:47:52 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: quickembed References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> Date: Wed, 14 Oct 2009 01:47:52 +0200 In-Reply-To: (quickembed@gmail.com's message of "Wed, 14 Oct 2009 07:28:29 +0800") Message-ID: <86my3uetzr.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arm@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm 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, 13 Oct 2009 23:47:53 -0000 quickembed writes: > Dag-Erling Sm=C3=B8rgrav writes: > > quickembed writes: > > > this error shows you have not indicate how to compile libgssapi.a > > > file. CC is for .c file, you need to tell what's for .a > > > (assembly) file. > > No, the command line is correct. Assembler sources end in .s or .S; > > .a is a static library. > Then it should be indicated how to "link". No. The Makefile is fine. One of the source files was missing an #include that contained inline functions or macros, which the compiler then assumed were external functions. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arm@FreeBSD.ORG Tue Oct 13 23:53:24 2009 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 AB0EF1065679; Tue, 13 Oct 2009 23:53:24 +0000 (UTC) (envelope-from franson@gmail.com) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by mx1.freebsd.org (Postfix) with ESMTP id 548298FC0A; Tue, 13 Oct 2009 23:53:24 +0000 (UTC) Received: by iwn27 with SMTP id 27so5296583iwn.7 for ; Tue, 13 Oct 2009 16:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=9WPWNqt0/8SOPg8A7FVMecz7C43AWaCmBNvQmufZkC8=; b=HG4sSF7641BoxLAI37Q/ODl+JcotkWTzUh6+j9LU0vUAxgfWaghzaLhc6yAc5g6H+v qoot/ZCdwRDYYhW7RS/bD/IC8AtfQixmWd1MjlHP2H5pt1/rkjvox+39dezFYIGLoO6u RUG5wPUUBsFZhJfkSDTXg0jRwiqpHAUgBKEOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MVsrdTGn2TMSMmXtqmEKTBK04ErZetNNw6NKjApLcyA+jTgZrIhY/2ovakVrF+XVcv 2XpI6bJp6L1nkDCBcjRoU9jDyMvBZym6IQLDSA2XLSY3R7TgUODVqyJoDmRVbVDbI7vs oRYUA82qjBrpWcMaGnOlH4O1Nj4YNvTLjxuVo= MIME-Version: 1.0 Sender: franson@gmail.com Received: by 10.231.26.131 with SMTP id e3mr4168337ibc.0.1255478003828; Tue, 13 Oct 2009 16:53:23 -0700 (PDT) In-Reply-To: <86my3uetzr.fsf@ds4.des.no> References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> <86my3uetzr.fsf@ds4.des.no> Date: Wed, 14 Oct 2009 07:53:23 +0800 X-Google-Sender-Auth: 57018901cf515f27 Message-ID: From: quickembed To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arm@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm 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, 13 Oct 2009 23:53:24 -0000 should not it say "unresolved external function...." etc if the compiler can not find the function body? 2009/10/14 Dag-Erling Sm=F8rgrav : > quickembed writes: >> Dag-Erling Sm=F8rgrav writes: >> > quickembed writes: >> > > this error shows you have not indicate how to compile libgssapi.a >> > > file. =A0CC is for .c file, you need to tell what's for .a >> > > (assembly) file. >> > No, the command line is correct. =A0Assembler sources end in .s or .S; >> > .a is a static library. >> Then it should be indicated how to "link". > > No. =A0The Makefile is fine. =A0One of the source files was missing an > #include that contained inline functions or macros, which the compiler > then assumed were external functions. > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > From owner-freebsd-arm@FreeBSD.ORG Wed Oct 14 00:06:45 2009 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 0464F1065696; Wed, 14 Oct 2009 00:06:45 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id B5E158FC19; Wed, 14 Oct 2009 00:06:44 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 09C826D41C; Wed, 14 Oct 2009 00:06:44 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id C766984537; Wed, 14 Oct 2009 02:06:43 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: quickembed References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> <86my3uetzr.fsf@ds4.des.no> Date: Wed, 14 Oct 2009 02:06:43 +0200 In-Reply-To: (quickembed@gmail.com's message of "Wed, 14 Oct 2009 07:53:23 +0800") Message-ID: <86aazuet4c.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arm@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm 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, 14 Oct 2009 00:06:45 -0000 quickembed writes: > should not it say "unresolved external function...." etc if the > compiler can not find the function body? Yes, that's exactly what it does: /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_= authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declara= tion of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declara= tion of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declara= tion of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declara= tion of function 'der_put_oid' DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arm@FreeBSD.ORG Wed Oct 14 07:05:44 2009 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 C0EF8106566B; Wed, 14 Oct 2009 07:05:44 +0000 (UTC) (envelope-from bland@FreeBSD.org) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 86D5C8FC0A; Wed, 14 Oct 2009 07:05:44 +0000 (UTC) Received: from hub.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id D7E6D7C18B; Wed, 14 Oct 2009 15:46:03 +0900 (JST) Received: from hub.bbnest.net (localhost [127.0.0.1]) by hub.bbnest.net (8.14.3/8.14.3) with ESMTP id n9E6jwe0076875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Oct 2009 15:45:58 +0900 (JST) (envelope-from bland@FreeBSD.org) Received: (from www@localhost) by hub.bbnest.net (8.14.3/8.14.3/Submit) id n9E6jwH3076874; Wed, 14 Oct 2009 15:45:58 +0900 (JST) (envelope-from bland@FreeBSD.org) X-Authentication-Warning: hub.bbnest.net: www set sender to bland@FreeBSD.org using -f To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= MIME-Version: 1.0 Date: Wed, 14 Oct 2009 15:45:58 +0900 From: Alexander Nedotsukov In-Reply-To: <86aazuet4c.fsf@ds4.des.no> References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> <86my3uetzr.fsf@ds4.des.no> <86aazuet4c.fsf@ds4.des.no> Message-ID: X-Sender: bland@FreeBSD.org User-Agent: RoundCube Webmail/0.2a Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Oct 14 15:46:03 2009 X-DSPAM-Confidence: 0.9991 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4ad573ab768763761837599 Cc: arm@FreeBSD.org, FreeBSD Tinderbox , current@FreeBSD.org Subject: Re: [head tinderbox] failure on arm/arm 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, 14 Oct 2009 07:05:44 -0000 Heh. You just repeat my mistake (presumably with a bit of help from my side though). Those warning lines are really provoking :-) While missed #include issue still true it was not a source of build failure. libgssapi_krb5 now have libgssapi as a dependency but stay first in the _prebuild_libs list and nothing said build framework why it must build it in a different order. I committed the fix yesterday: http://svn.freebsd.org/viewvc/base?view=revision&revision=198020 Alexander. ps. I noticed that mails from tinderbox.freebsd.org contains link to not existed tinderbox.des.no host. On Wed, 14 Oct 2009 02:06:43 +0200, Dag-Erling Smørgrav wrote: > quickembed writes: >> should not it say "unresolved external function...." etc if the >> compiler can not find the function body? > > Yes, that's exactly what it does: > > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function > 'gsskrb5_extract_authz_data_from_sec_context': > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit > declaration of function 'der_get_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit > declaration of function 'der_free_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit > declaration of function 'der_length_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit > declaration of function 'der_put_oid' > > DES From owner-freebsd-arm@FreeBSD.ORG Thu Oct 15 13:40:19 2009 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 C5A27106566C for ; Thu, 15 Oct 2009 13:40:19 +0000 (UTC) (envelope-from asientrade@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id 0151D8FC13 for ; Thu, 15 Oct 2009 13:40:19 +0000 (UTC) Received: from [195.4.92.20] (helo=10.mx.freenet.de) by mout1.freenet.de with esmtpa (ID asientrade@freenet.de) (port 25) (Exim 4.69 #92) id 1MyQZ0-0004bN-CY for freebsd-arm@freebsd.org; Thu, 15 Oct 2009 15:40:18 +0200 Received: from p5b12da1b.dip.t-dialin.net ([91.18.218.27]:58196 helo=daniel-PC) by 10.mx.freenet.de with esmtpa (ID asientrade@freenet.de) (port 587) (Exim 4.69 #94) id 1MyQYq-0000LO-1L for freebsd-arm@freebsd.org; Thu, 15 Oct 2009 15:40:18 +0200 From: "daniel" To: freebsd-arm@freebsd.org Content-Type: multipart/related; boundary="----=_NextPart_766_F636_E7973656.97579622" MIME-Version: 1.0 Date: Thu, 15 Oct 2009 15:40:35 +0200 Message-Id: <20091015154032A38C60EA7A$50739F2991@DANIELPC> Status: N X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Twitter-endlich Geldverdienen-kostenlos und sofort startklar X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bitteinfo1@freenet.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 13:40:19 -0000 This is a multi-part message in MIME format ------=_NextPart_766_F636_E7973656.97579622 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =A0Offers stand below as an English available Hallo- =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 verdiene endlich Geld durc= h Twitterwenn ein Twitter Account vorhanden sein sollte dann gehts sofort = los mit Verdienen.sollte keine Account vorhanden sein dann einfach alles kostenlos erstellen und verdienen.=A0mit besten Empfehlungen eure Danielleichter kann man sein =B4Geld nicht verdienen- alles kostenlos we= nn sie einen Twitteraccount haben.Also schnell handel-bei weiterem Interess= e und lust an gratis produkten einfach kurz anmelden-oder abmelden-- danke=A0=A0Anmelden=A0=A0=A0=A0=A0=A0 =A0Abmelden=A024 Std. Blitzangebot= =A0nur begrenzt f=FCr=A024 Stunden aktiv danach ausverkauft--- http://www.affiliateverkaufen.de/blitzangebot.html=A0=A0=A0=A0 10,-?(The= Logo Creator hilft beim Erstellen qualitativ hochwertiger Logos. Ganz nach de= m Motto "Your Logo is your business" gestaltet der Nutzer mit diesem Progr= amm Blickf=E4nger f=FCr Webseiten)=A0(=DCbersetzen Sie ganz einfach und mit = wenigen Klicks Texte oder sogar komplette Webseiten in 31 Sprachen. )nur 28,-?=A0= oder Aktionspreis 30,-?=A0=A0 f=FCr Logocreator v5 und PDF-Converter 6.0 dt.=A0= Oder m=F6chten sie lieber effektiv heute noch Geld verdienen und Zahlungen we= nn m=F6glich sofort erwirtschaften-?? dann mit diesem angebot was f=FCr mich selbstbehauptet das beste =FCberh= aupt war und ist--Geld durch Emails verdienen-aber keine centbetr=E4ge sonder= n sofort 10-20,-? sofort-zahlung innerhalb weniger minuten, ich habe zur zeit zwischen 5 und 20 Kunden pro tag (weltweit) bei einem verdienst pro emai= l von ca. 15,-? und ich betreibe keinerlei werbung oder verkaufe durchs telefon nein die= Kunden kommen zu mir und ich verdiene sehr gut-aber lesen sie selbst wen= n ihr interesse noch vorhanden ist weiter im Angebot 2.erfolgreiches Hande= ln w=FCnsche ich auf diesem Wege-bei weiteren Interessen k=F6nnen sie sichwiederholt eintragen um weitere Angebote und Gratis Geschenke zu erhalten........................(oder Abmelden).... Anmelden=A0=A0=A0=A0= Abmelden =A0Hello- finally earn money by Twitterthen immediately feels wrong with= earning if a Twitter account should be available. no-one should account = be available simply then everything free of charge make and earn. with bes= t recommendations yours Danielone can more easily money not earning everything be ' free if they have a Twitteraccount. -therefore act fast = simply registering or cancelling at broader interest and desire at free = products briefly, thank youBookingCancelling24 hour lightning supply=A0s= old off according to that actively for 24 hours only restrictedly - http://www.affiliateverkaufen.de/blitzangebot.html 10. ? (A The logo Creator helps to make high-quality logos. According to the motto "Your l= ogo is your business" the user completely forms with this programme eye-catc= her for web pages.) =A0 (Translate texts or even complete web pages for onl= y simply and a few clicks into 31 languages.) only 28. ? or special-offer= price 30. ? for Logocreator v5 and PDF-Converter of 6.0 dt. -or they wo= uld rather, today, still earn money effectively and immediately gain payment= s if possible? with this supply did but no cent amounts what was self claimed for me th= e best at all and is? I have 10-20,- ? immediately payment within less minutes, between 5 and = 20 customers per day (worldwide) at an income per e-mail from approx. 15. ?= at the moment by the telephone the customers no come to me and I earn very well and I = operate no advertising or sell but read them even if their interest is still further existing in the supply 2. Angebot 2.I wish on this at broa= der interests be able to do them himself a successful action waystyping repeated ........................ in to receive further offers and free = presents. (or cancel ) ..... Booking=A0 Cancelling=A0=A0=A0=A0 ------=_NextPart_766_F636_E7973656.97579622--