From owner-freebsd-arm@FreeBSD.ORG Mon Nov 1 11:06:52 2010 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 E9F061065674 for ; Mon, 1 Nov 2010 11:06:52 +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 D70AF8FC16 for ; Mon, 1 Nov 2010 11:06:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA1B6qbO019102 for ; Mon, 1 Nov 2010 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA1B6qtK019100 for freebsd-arm@FreeBSD.org; Mon, 1 Nov 2010 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Nov 2010 11:06:52 GMT Message-Id: <201011011106.oA1B6qtK019100@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, 01 Nov 2010 11:06:53 -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/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 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 4 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Nov 1 12:14:32 2010 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 10DAB106566B for ; Mon, 1 Nov 2010 12:14:32 +0000 (UTC) (envelope-from romain@blogreen.org) Received: from marvin.blogreen.org (unknown [IPv6:2a01:e35:2f7d:58c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8E1948FC15 for ; Mon, 1 Nov 2010 12:14:31 +0000 (UTC) Received: by marvin.blogreen.org (Postfix, from userid 1001) id 23909C17A; Mon, 1 Nov 2010 13:14:28 +0100 (CET) Date: Mon, 1 Nov 2010 13:14:27 +0100 From: Romain =?iso-8859-1?Q?Tarti=E8re?= To: arm@freebsd.org Message-ID: <20101101121427.GA51560@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline X-PGP-Key: http://romain.blogreen.org/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: [patch] Fix for named(8) on OpenRD 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, 01 Nov 2010 12:14:32 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello I have a long-standing issue I fixed locally but might interest OpenRD users (and probably SheevaPlug users and maybe even more) to fix named(8). Basically, named(8) crashes at startup. I searched this list archives and found 2-3 interesting posts with partial fixes, and merging-up them all together I got a patch [1] that allowed named(8) to start and run. For various reasons, I had not the time to test it extensively: I saw it worked, tested it ~5mn and rebooted on another FreeBSD system on the device because it provides some services I depend on and downtime is a problem. However, I am not filling-in a PR right now because: - I have no knowledge of ARM assembler and have basically no idea about how the fix does it's job; - I have not enough knowledge about ARM to say if this fix will break other ARM based systems or not. I guess there are people on the list who will have the expertise I am lacking in this area. Thanks you for your feedback! Romain References: 1. http://people.freebsd.org/~romain/openrd-named.diff --=20 Romain Tarti=E8re http://people.FreeBSD.org/~romain/ pgp: 8234 9A78 E7C0 B807 0B59 80FF BA4D 1D95 5112 336F (ID: 0x5112336F) (plain text =3Dnon-HTML=3D PGP/GPG encrypted/signed e-mail much appreciated) --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQGcBAEBAgAGBQJMzq8hAAoJELpNHZVREjNv620L+wTHPYI1c37Y2tuPoncWbmsB C1y0qlkJE7XU72cZGt9HqN1SZFiJL4XbZfTtCjwKg01iJV+CLuwer5pazkJsfhs6 ItA8C2IJeSmnvnpVRf2k6Qs6MiTvACMH20fCG89j/vv3PIfZfYPEuLxU+osXvoko Z83IJIsfcjZd/qZ/GowsO3TSmcy3Dn+d26DpGgVeC9OwfTw1rYzVW03wQb9OKkKq 5IdtOZ3cmGa86tJ2o6BFcFPruGislDh0+l+uEXyB8RqeUzyAJFiy+cwrNkxOkyb4 iO0YPOMTfVd5p2fA4FSEGNw4rX5uvpPeBDE8qJfYcAaIgeMw0mHfZc8kDBN8ChyL iJceoeiAyeyrUTXUGmunkIqSZUsV6xqHxx6cdbZzffS5RDex7EwsUt2x+ajAPWVb 8tXarv/0TnOc6ph75DUZUgHaq0IMBlEGGYAgPfCodrMemjQk1HcJ34d6PNmv8aK3 KpLrNMvGTUmBK2eNvoHnRLjcG4vD/hc1ashvrDSMTA== =kgUW -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-arm@FreeBSD.ORG Mon Nov 1 12:52:33 2010 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 95D6D1065670; Mon, 1 Nov 2010 12:52:33 +0000 (UTC) (envelope-from johny.mattsson@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id F359F8FC12; Mon, 1 Nov 2010 12:52:32 +0000 (UTC) Received: by wwb17 with SMTP id 17so81229wwb.31 for ; Mon, 01 Nov 2010 05:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=mVvgM/EVliF/fbY89LQM2ka3DhfqNTwXga7HYu64pCU=; b=K1VtQdkLkaeKuXCDQK3m/UlAl9SjWxCpbmpFn7I/agSD6dejhh9W49VLuTS9gLzEje gOKbeWS8h4cw7TT6arOZ+NXhOd70PvKIVkWxQjG1CDshmxgD1grcrGyEqaVDcUXgYJTr fl91nE1bxqflt+fO8iyGXWktlFQpOp8AVCtNA= 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=nVIuK75pC7KBQd9KnRzSdP4VkKWQEgj5Z+ijfKMyhyza32iRqwRb2Euqk+Yc5tccUT 0mHwhF986ttGUMq6CMKuACaGhvg8+dDjIU0MEhMFlRTpvM8Xt+Ol3dYIjRo18J9h1K8m p4C1sjEjLkfopQkYB5VOCY5p9kFQUjbr0SdKM= MIME-Version: 1.0 Received: by 10.216.51.21 with SMTP id a21mr2424503wec.50.1288614055427; Mon, 01 Nov 2010 05:20:55 -0700 (PDT) Sender: johny.mattsson@gmail.com Received: by 10.216.185.18 with HTTP; Mon, 1 Nov 2010 05:20:55 -0700 (PDT) In-Reply-To: <20101101121427.GA51560@FreeBSD.org> References: <20101101121427.GA51560@FreeBSD.org> Date: Mon, 1 Nov 2010 23:20:55 +1100 X-Google-Sender-Auth: kSOIoJe6UE2D4S2sZ_-MYNSYyDE Message-ID: From: Johny Mattsson To: =?UTF-8?Q?Romain_Tarti=C3=A8re?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: arm@freebsd.org Subject: Re: [patch] Fix for named(8) on OpenRD 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, 01 Nov 2010 12:52:33 -0000 2010/11/1 Romain Tarti=C3=A8re : > I have a long-standing issue I fixed locally but might interest OpenRD > users (and probably SheevaPlug users and maybe even more) to fix > named(8). Hmm, this looks remarkably like the patch I tried the other day when I encountered the crashing named problem, but it did not improve my situation. I'll see if I can find time and opportunity to test it again. My workaround was to pull in the latest named from ports, which has been running fine for me. Regards, /Johny From owner-freebsd-arm@FreeBSD.ORG Mon Nov 1 15:19:04 2010 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 8A0F81065701 for ; Mon, 1 Nov 2010 15:19:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id C379F8FC13 for ; Mon, 1 Nov 2010 15:19:02 +0000 (UTC) Received: from [10.0.0.182] (182.imp.bsdimp.com [10.0.0.182] (may be forged)) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id oA1FA7EB006730 for ; Mon, 1 Nov 2010 09:10:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Message-ID: <4CCED84F.6030304@bsdimp.com> Date: Mon, 01 Nov 2010 09:10:07 -0600 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <20101101121427.GA51560@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [patch] Fix for named(8) on OpenRD 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, 01 Nov 2010 15:19:04 -0000 On 11/01/2010 06:20, Johny Mattsson wrote: > 2010/11/1 Romain Tartière: >> I have a long-standing issue I fixed locally but might interest OpenRD >> users (and probably SheevaPlug users and maybe even more) to fix >> named(8). > Hmm, this looks remarkably like the patch I tried the other day when I > encountered the crashing named problem, but it did not improve my > situation. I'll see if I can find time and opportunity to test it > again. > > My workaround was to pull in the latest named from ports, which has > been running fine for me. > Somewhere, there were patches floating around for this that I thought wound up in the tree.. Which version are you guys using? -current? Warner > Regards, > /Johny > _______________________________________________ > 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 Mon Nov 1 18:54:27 2010 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 70ECE1065670 for ; Mon, 1 Nov 2010 18:54:27 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3419A8FC08 for ; Mon, 1 Nov 2010 18:54:26 +0000 (UTC) Received: by iwn39 with SMTP id 39so7318302iwn.13 for ; Mon, 01 Nov 2010 11:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=MuR5/Zs9rjHen1HZ+/p9D58ORsN0Ai0VwpaxHjywMtI=; b=UuBPgbvVD/1qpwbQrFIYJ72OnFGtvLkbBLVVSsXv1nAkx5v2DyddWc6Kp1YDyI8mmq XM/4bQ7RhLbkGA0YgqlQGmsm14d+QHrt1oV4TCCgMubpBJxevCTxqne6KHpN2oq1EeTS akszOT4pf5TqO2pWJKZmpVnf06PhOyyulXaOw= 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; b=MqjMDcTwEAYj0tnOerCaOYE7w3Gc7NE7LIKyIvyqFWxVFdCv0r79fdJZzRucuNkGw4 hGTeHM7LARAl8HKKtzQfkWrxBVtuI8Ig8u1KC06chheWBG8DdSAkqABo8Knfr7M/gzR+ hclRumHE06lruTj5b6gIQ4AnhUxwodiT6lHbA= MIME-Version: 1.0 Received: by 10.231.16.67 with SMTP id n3mr1968621iba.113.1288637665161; Mon, 01 Nov 2010 11:54:25 -0700 (PDT) Received: by 10.231.172.73 with HTTP; Mon, 1 Nov 2010 11:54:25 -0700 (PDT) In-Reply-To: <4CCED84F.6030304@bsdimp.com> References: <20101101121427.GA51560@FreeBSD.org> <4CCED84F.6030304@bsdimp.com> Date: Mon, 1 Nov 2010 13:54:25 -0500 Message-ID: From: Mark Tinguely To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arm@freebsd.org Subject: Re: [patch] Fix for named(8) on OpenRD 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, 01 Nov 2010 18:54:27 -0000 On Mon, Nov 1, 2010 at 10:10 AM, Warner Losh wrote: > On 11/01/2010 06:20, Johny Mattsson wrote: > >> 2010/11/1 Romain Tarti=E8re: >> >>> I have a long-standing issue I fixed locally but might interest OpenRD >>> users (and probably SheevaPlug users and maybe even more) to fix >>> named(8). >>> >> Hmm, this looks remarkably like the patch I tried the other day when I >> encountered the crashing named problem, but it did not improve my >> situation. I'll see if I can find time and opportunity to test it >> again. >> >> My workaround was to pull in the latest named from ports, which has >> been running fine for me. >> >> Somewhere, there were patches floating around for this that I thought > wound up in the tree.. > > Which version are you guys using? -current? > > Warner > > Regards, >> /Johny >> > The mail archives says this came up in Feb 2010. I said then and I will say again, we should add a cmpxchg() command to the library, or IMO a better place, include/machine/atomic.h. --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Mon Nov 1 19:28:35 2010 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 6842D106564A for ; Mon, 1 Nov 2010 19:28:35 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1714A8FC0A for ; Mon, 1 Nov 2010 19:28:34 +0000 (UTC) Received: by yxl31 with SMTP id 31so3744049yxl.13 for ; Mon, 01 Nov 2010 12:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ndnU96IXG6llxhQX4/RTuSg/oQDip2FPPJWfxc8SKjM=; b=XdFM1ZCFaV49d2J52eQD7XziE5eY1WxvrfzJTGi/4Qz3kBApBUhwivu5M0QNptQpET EnvDTw/KMjDpnRWIIYhqKfwTyQU6E7wCu31oKT/UdhPOO42Mbn3009RpT/p7GJXwK1U7 KysTkmGuPqHVPGCojbdJiKM7AKPdccXex7UAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=aZe0IRcD7AcOr30I5ox9QDBcX+DrnC73RCUaVIBsT24jVZsmMGb5d3q22xoSewfW69 9yrqUvR6IG75hMFw0HZE2lTNMaBpP5nuRBjetyUsVVRCCtl4vzPgbWTzRSrz6O+ST6Vy cb/bh2LqrkO86icztibuXOv1rlcxUiqACDH/g= Received: by 10.229.91.2 with SMTP id k2mr11021174qcm.147.1288639713924; Mon, 01 Nov 2010 12:28:33 -0700 (PDT) Received: from [192.168.0.100] (71-38-48-15.frgo.qwest.net [71.38.48.15]) by mx.google.com with ESMTPS id p32sm3241999vbl.5.2010.11.01.12.28.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Nov 2010 12:28:33 -0700 (PDT) Message-ID: <4CCF14DB.1090304@gmail.com> Date: Mon, 01 Nov 2010 14:28:27 -0500 From: Mark Tinguely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Warner Losh References: <20101101121427.GA51560@FreeBSD.org> <4CCED84F.6030304@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: [patch] Fix for named(8) on OpenRD 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, 01 Nov 2010 19:28:35 -0000 Mark Tinguely wrote: > > The mail archives says this came up in Feb 2010. I said then and I > will say again, we should add a cmpxchg() command to the library, or > IMO a better place, include/machine/atomic.h. > > --Mark Tinguely > It does exist. Is there a reason bind9 does not use atomic_cmpset_32()? --Mark "the embarrassed". From owner-freebsd-arm@FreeBSD.ORG Mon Nov 1 22:40:34 2010 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 A58D0106566C for ; Mon, 1 Nov 2010 22:40:34 +0000 (UTC) (envelope-from romain@blogreen.org) Received: from marvin.blogreen.org (unknown [IPv6:2a01:e35:2f7d:58c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2CED28FC18 for ; Mon, 1 Nov 2010 22:40:34 +0000 (UTC) Received: by marvin.blogreen.org (Postfix, from userid 1001) id 25DD1C446; Mon, 1 Nov 2010 23:40:33 +0100 (CET) Date: Mon, 1 Nov 2010 23:40:33 +0100 From: Romain =?iso-8859-1?Q?Tarti=E8re?= To: freebsd-arm@freebsd.org Message-ID: <20101101224032.GB56723@FreeBSD.org> References: <20101101121427.GA51560@FreeBSD.org> <4CCED84F.6030304@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JgQwtEuHJzHdouWu" Content-Disposition: inline In-Reply-To: <4CCED84F.6030304@bsdimp.com> X-PGP-Key: http://romain.blogreen.org/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [patch] Fix for named(8) on OpenRD 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, 01 Nov 2010 22:40:34 -0000 --JgQwtEuHJzHdouWu Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi On Mon, Nov 01, 2010 at 09:10:07AM -0600, Warner Losh wrote: > Which version are you guys using? -current? I tested the patch on -CURRENT in January. I had no time to test again right now, but before the patch gets even more stale, I though I had to 'speak about it' when I saw some SheevaPlug related messages in the past few days (I just checked that the code was still the same in -CURRENT as of today just in case.). I can't guarantee I will have the time to test proposed solution but will do my best to make some. Thanks! Romain --=20 Romain Tarti=E8re http://people.FreeBSD.org/~romain/ pgp: 8234 9A78 E7C0 B807 0B59 80FF BA4D 1D95 5112 336F (ID: 0x5112336F) (plain text =3Dnon-HTML=3D PGP/GPG encrypted/signed e-mail much appreciated) --JgQwtEuHJzHdouWu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQGcBAEBAgAGBQJMz0HeAAoJELpNHZVREjNveOgMAIYGBrHktgfzGnIcDFbbfB10 cJOuQqTTlPDsXrzFiNra9N1rnzo6tEeGEuOuHmpHI+4Q9tzzN958tPKZYhO3K0rg FxgWeFYNQGcnNEadnBrw1dLtAThR4lbGewyzcoGMmpsFfASPls2T4NGBTkb4My70 IoIFvk4gyt/FQPzxVjkv+W6BQOcbNrlm8Qenw+Zvp3hXOLMAxpwsLZyHvMQ4RvQf qrPodKsbdAznLTgxgr8KZKD1VFAhUDhw0Gu5qiHLicDE/ayTluiGEsYKe31laK/6 BjXsuvSzYjftUYunkGoptro6xFiAfJyk22v29WkdVjCdhjYrXFFzpRLvHXSeczNv 4ynWzqsDMCmtESalPbjexMVBqpF1/WaOK0RxbzxVSxJcew4DTpue+xYjPNd9Ocaw lbl9OnSd7ZwPXNpIjMDo2F9W6MWUIZPm7FUYlUHKoFhyYRlUrcFwEWZPQBV0M/po WFAXsTwCVe3vDuOcszN4pzk8IbpIktW+p+sOPR1q6Q== =R0Dg -----END PGP SIGNATURE----- --JgQwtEuHJzHdouWu-- From owner-freebsd-arm@FreeBSD.ORG Tue Nov 2 21:43:25 2010 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 595C4106566B for ; Tue, 2 Nov 2010 21:43:25 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id C12108FC12 for ; Tue, 2 Nov 2010 21:43:24 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Tue, 02 Nov 2010 22:43:35 +0100 id 00033C0F.4CD08607.0000A6C9 From: Milan Obuch To: Rafal Jaworowski Date: Tue, 2 Nov 2010 22:43:31 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201010202309.40148.freebsd-arm@dino.sk> <201010272259.36319.freebsd-arm@dino.sk> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011022243.33116.freebsd-arm@dino.sk> Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug Server Plus working to some extent... [mge1 problem SOLVED] 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, 02 Nov 2010 21:43:25 -0000 On Saturday 30 October 2010 15:02:43 Rafal Jaworowski wrote: > On 2010-10-27, at 22:59, Milan Obuch wrote: > > On Wednesday 27 October 2010 18:44:23 Rafal Jaworowski wrote: [snip] > > > > One issue still remains - mge1 has no unique ether address, all-zero is > > set upon reboot unless explicitly set in dts. This is small issue for > > me, need not be resolved urgently. > > This issue is not easily resolved in general. U-Boot would only initialize > MAC address in registers of an Ethernet controller, which was used at > least once. If an Ethernet controller unit is not used at the U-Boot stage > its MAC address registers remain uninitialized. Now, in our case the OS > can only learn about MAC address either from DT or (in case there are all > 0's) fall back to whatever was set by the firmware. > For now I found simple and effective solution (maybe not nice, but that's just matter of taste, anyway). I modified U-Boot's environment, so now there are following variables set: bootcmd=setenv ethact egiga1; ${x_bootcmd_ethernet}; setenv ethact egiga0; ${x_bootcmd_ethernet}; tftpboot kernel.bin; go 800000 x_bootcmd_ethernet=ping 192.168.16.1 ipaddr=192.168.16.5/24 serverip=192.168.16.133 This is not permanent and nice solution, but sufficient for now. This way, firmware sets both interfaces' ether address. Milan From owner-freebsd-arm@FreeBSD.ORG Tue Nov 2 22:02:35 2010 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 793B8106564A for ; Tue, 2 Nov 2010 22:02:35 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 3A50E8FC08 for ; Tue, 2 Nov 2010 22:02:34 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Tue, 02 Nov 2010 23:02:47 +0100 id 00033C0F.4CD08A87.0000A857 From: Milan Obuch To: Oleksandr Tymoshenko Date: Tue, 2 Nov 2010 23:02:38 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201010300037.03374.freebsd-arm@dino.sk> <201010301900.36922.freebsd-arm@dino.sk> <04048D7D-DF99-4CC6-A4D0-C59C6BBE0DF8@bluezbox.com> In-Reply-To: <04048D7D-DF99-4CC6-A4D0-C59C6BBE0DF8@bluezbox.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011022302.39468.freebsd-arm@dino.sk> Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug gpio 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, 02 Nov 2010 22:02:35 -0000 On Sunday 31 October 2010 00:17:51 Oleksandr Tymoshenko wrote: > On 2010-10-30, at 10:00 AM, Milan Obuch wrote: > > On Saturday 30 October 2010 15:18:54 Rafal Jaworowski wrote: > >> On 2010-10-30, at 00:37, Milan Obuch wrote: > >>> Hi, > >>> > >>> after solving mge1 problem I decided to work a bit with Guruplug's > >>> gpio. There are some of them accessible via u-snap connector and some > >>> of them are used to controll status LEDs. > >> > >> As mentioned in another email, Marvell GPIO driver does not get hooks > >> for the new framework, so this needs to be provided first before you'd > >> be able to controll LEDs from userspace etc. > > > > I see. I am going to investigate how this could be done. I did some work > > with GPIO based on some older work, so I just need to check the > > infrastructure for GPIO (gpiobus, gpio properties etc). > > Bear in mind that GPIO framework is work ing progress and its abilities > are very limited at the moment. Feel free to send patches or feature > requests I copied parts of sys/mips/atheros, modified them and put into sys/arm/mv/gpio.c, so I have now possibility to get/set gpio pins. Pin description and setup is for now hardcoded in source. I would like to put description/initialize/setup info into dts file, but I need good description or (even better) working dts file with gpios property, so I can see how it is intented to be done and modify the code. Code needs some polishing as well, as a really quick hack it is not suitable for review. As soon as I can clean it a bit, I would like to get it reviewed. Before that, is there some FreeBSD gpio framework description available? Regards, Milan From owner-freebsd-arm@FreeBSD.ORG Wed Nov 3 16:08:45 2010 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 68FD310656A6 for ; Wed, 3 Nov 2010 16:08:45 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 299028FC26 for ; Wed, 3 Nov 2010 16:08:44 +0000 (UTC) Received: by iwn39 with SMTP id 39so876005iwn.13 for ; Wed, 03 Nov 2010 09:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=8Noi+zPYpVnmGJovet8WLsExN4c6ZmvtLESK6DlFDmw=; b=FZZQkNc0w6fS0nkDhzCZVkQpc730OrXo3+Xq40fo4+VsCDY+ZhL+uWRHRaPn3xy6rV xQWRYw6Nhi1+nMNod8dV2OQ8Sqjmv0TMo8pDaHV3tpL19M9dEfKbFmu7/whnIvBftBKY Ri0+O8M71Hl0jvCdeXVJ0EDOFBmhraWO4ihVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=uDJ4n2vDFrq3xq4Smbusu4pReB0GEZ2UDIk+n/MGLTQNcaHI9UHXtpfE7wLExEk1Ri KgR3vxDaa51cvb4e4+v+YQSCZArAxaRPFVv5eYHRb38IBu+9OYCAPUO/wdRlfn3mu2X3 EzMUiDBZUQoAxfS4pT2Cj29xQSM0GOpwe2XCo= Received: by 10.231.33.4 with SMTP id f4mr3918715ibd.188.1288800524235; Wed, 03 Nov 2010 09:08:44 -0700 (PDT) Received: from [192.168.0.100] (71-38-48-15.frgo.qwest.net [71.38.48.15]) by mx.google.com with ESMTPS id u6sm11454123ibd.12.2010.11.03.09.08.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Nov 2010 09:08:43 -0700 (PDT) Message-ID: <4CD18907.1080209@gmail.com> Date: Wed, 03 Nov 2010 11:08:39 -0500 From: Mark Tinguely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Olivier Houchard References: <4B951CE2.6040507@semihalf.com> <201003221455.o2MEt4V5068925@casselton.net> <20100322150633.GA18277@ci0.org> In-Reply-To: <20100322150633.GA18277@ci0.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Tinguely , freebsd-arm@FreeBSD.ORG Subject: (for archive) 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, 03 Nov 2010 16:08:45 -0000 Olivier Houchard wrote: > On Mon, Mar 22, 2010 at 09:55:04AM -0500, Mark Tinguely wrote: > >> On Mon, 08 Mar 2010 16:50:58, Grzegorz Bernacki said: >> >> >>> This is probably caused by mechanism which turns of cache for shared pages. >>> When I add applied following path: >>> >>> diff --git a/sys/arm/arm/pmap.c b/sys/arm/arm/pmap.c >>> index 390dc3c..d17c0cc 100644 >>> --- a/sys/arm/arm/pmap.c >>> +++ b/sys/arm/arm/pmap.c >>> @@ -1401,6 +1401,8 @@ pmap_fix_cache(struct vm_page *pg, pmap_t pm, vm_offset_t va) >>> */ >>> >>> TAILQ_FOREACH(pv, &pg->md.pv_list, pv_list) { >>> + if (pv->pv_flags & PVF_EXEC) >>> + return; >>> /* generate a count of the pv_entry uses */ >>> if (pv->pv_flags & PVF_WRITE) { >>> if (pv->pv_pmap == pmap_kernel()) >>> >>> execution time of 'test' program is: >>> mv78100-4# time ./test >>> 5.000u 0.000s 0:05.40 99.8% 40+1324k 0+0io 0pf+0w >>> >>> and without this path is: >>> mv78100-4# time ./test >>> 295.000u 0.000s 4:56.01 99.7% 40+1322k 0+0io 0pf+0w >>> >>> >>> I think we need to handle executable pages in different way. >>> >>> grzesiek >>> >> Good going Oliver and thank-you on the pmap_enter_pv kernel map patch Revision >> 205425. >> >> Last week, before this patch, Maks Verver was so kind to put some statements >> in the VM (vm_page_free_toq()) for the SheevaPlug because I could not cause >> these paths with the Gumstix emulator. Maks, could you add to >> vm_phys_free_pages(): >> >> if (m->md.pv_kva) >> + { >> + printf("vm_phys_free_pages: md.pv_kva 0x%08x\n", m->md.pv_kva); >> m->md.pv_kva = 0; >> + } >> >> Even on the Gumstix emulator with the current patch, pmap_fix_cache() still >> has many executable pages that have both a kernel and user pv_entry. Looks >> like something like the above patch is still needed. >> >> > > I added a few printf and saw the same thing, however isn't assuming we > shouldn't modify the cache settings if the page is executable a bit dangerous ? > Or did I misread your patch ? > > Olivier > > I am cleaning up my old files. I thought I would put some numbers to this old thread into the archive in case this comes up again. Warning: The bus dma sync code for VIVT caches will only perform cache sync operations on the calling virtual address. It works correctly because the I/O request maps the page to a KVA and uses this address to perform the I/O. If the page is becomes shared when mapped to the KVA, then pmap_fix_cache routine cleans out the cache for every current share mapping and disables the cache on the page table entry. We are talking about NOT performing the cache operations on a shared executable. I think this will not be a problem for reading an executable page for the follow reasons: 0) I/O may cause a context change and flush the caches anyway. (very weak reason). 1) We should not be changing the contents of the executable file while the program is active without performing caches operations. 2) The executable page has been previously accessed and leaving part of the executable contents in the level 1 cache, then there should also be a RAM cached version in the buffer cache and we won't do DMA. --- I put some counters into pmap_fix_cache and found that: About 1% of the calls to pmap_fix_cache that has at least one executable mapping, also has one mapping that is not executable. In other words, the vast majority of executable pages have only executable mappings. About 89% of the pages that call pmap_fix_cache, also share the page with another pmap. It appears most are shared with another user pmap. About 4% of the pages that call pmap_fix_cache has at least one writable mapping. Of those pages that call pmap_fix_cache that have at least one writable mapping; About 80% of time, this is a user mapped write. IMO, user mapped writes must perform the cache operations. I came up with a modification that ignores the cache fixing only for the kernel mapped writes. I don't know if this too conservative to do any good, but it should be safer than ignoring the cache maintenance routines for all executable mappings. Index: arm/arm/pmap.c =================================================================== --- arm/arm/pmap.c (revision 214743) +++ arm/arm/pmap.c (working copy) @@ -1309,6 +1309,7 @@ int pmwc = 0; int writable = 0, kwritable = 0, uwritable = 0; int entries = 0, kentries = 0, uentries = 0; + int exec = 0, ncaches = 0; struct pv_entry *pv; mtx_assert(&vm_page_queue_mtx, MA_OWNED); @@ -1335,7 +1336,19 @@ uentries++; entries++; } + if (pv->pv_flags & PVF_EXEC) + exec++; + if (pv->pv_flags & PVF_NC) + ncaches++; } + /* don't cache if there is kernel mapping to otherwise + * read-only executable mappings. + */ + if (exec && (exec == entries + kentries) && + (writable == 0 || (writable == kwritable)) && + (ncaches == 0)) + return; + /* * check if the user duplicate mapping has * been removed. The conditions that I chose to bypass the cache operations are: (line 1) pure executable mapped page. (line 2) either not writable or only writable to the kernel map (cluster IO can make this >1) (line 3) this is not a request to turn caches back on. --Mark.