From owner-freebsd-arm@FreeBSD.ORG Sun Mar 7 01:40:01 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 BF479106564A for ; Sun, 7 Mar 2010 01:40:01 +0000 (UTC) (envelope-from maksverver@geocities.com) Received: from mx.utwente.nl (mx2.utsp.utwente.nl [130.89.2.13]) by mx1.freebsd.org (Postfix) with ESMTP id 3C5078FC17 for ; Sun, 7 Mar 2010 01:40:00 +0000 (UTC) Received: from heaven.student.utwente.nl (heaven.student.utwente.nl [130.89.167.52]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o271dro2020425 for ; Sun, 7 Mar 2010 02:39:53 +0100 Message-ID: <4B9303E4.3090500@geocities.com> Date: Sun, 07 Mar 2010 02:39:48 +0100 From: Maks Verver User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100209 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <4B92BD9D.6030709@geocities.com> <20100306211715.GK58319@cicely7.cicely.de> <20100306215153.GL58319@cicely7.cicely.de> <20100306.152603.716362616846278503.imp@bsdimp.com> In-Reply-To: <20100306.152603.716362616846278503.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: maksverver@geocities.com X-Spam-Status: No Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 01:40:01 -0000 On 03/06/2010 10:17 PM, Bernd Walter wrote: > Such massive speed difference sounds a bit like cache problems. On 03/06/2010 11:26 PM, M. Warner Losh wrote: > Sounds a lot like ICACHE isn't being enabled, since a 3-liner like > this should be executing entirely out of cache after the first > instruction in main prefetches the cache line. Thanks for the quick responses! I think the both of you are right. I didn't realize the cache could be turned off at all, but the boot output shows: CPU: Feroceon 88FR131 rev 1 (write-through core) WB enabled EABT branch prediction enabled 16KB/32B 4-way Instruction cache 16KB/32B 4-way write-back-locking-C Data cache This is different from the output on the wiki (which instructions I followed, to some extent) at http://wiki.freebsd.org/FreeBSDMarvell: CPU: ARM926EJ-S rev 0 (ARM9EJ-S core) DC enabled IC enabled WB enabled EABT branch prediction enabled 32KB/32B 1-way Instruction cache 32KB/32B 4-way write-back-locking-C Data cache Note that this guy is not running a SheevaPlug; the CPU is different. But it's clear enough that on my system both processor caches are disabled (even though they are correctly identified) and this is understandably catastrophic for performance. It's good to have that figured out at least. :-) The logical next question is: why aren't these caches enabled? How is this supposed to work? Is the bootloader supposed to enable the cache, or the kernel? If the kernel, why isn't it doing this? (If it's the bootloader's task, then it's strange that the Linux kernel has no trouble enabling the cache with the same bootloader). Kind regards, Maks Verver. From owner-freebsd-arm@FreeBSD.ORG Sun Mar 7 07:00:17 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 E3F591065670 for ; Sun, 7 Mar 2010 07:00:16 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 63DAD8FC25 for ; Sun, 7 Mar 2010 07:00:16 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o2770E4C028464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 7 Mar 2010 08:00:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o2770BZY047307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Mar 2010 08:00:11 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o2770BBC009311; Sun, 7 Mar 2010 08:00:11 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o2770Akh009310; Sun, 7 Mar 2010 08:00:10 +0100 (CET) (envelope-from ticso) Date: Sun, 7 Mar 2010 08:00:10 +0100 From: Bernd Walter To: Maks Verver Message-ID: <20100307070010.GO58319@cicely7.cicely.de> References: <4B92BD9D.6030709@geocities.com> <20100306211715.GK58319@cicely7.cicely.de> <20100306215153.GL58319@cicely7.cicely.de> <20100306.152603.716362616846278503.imp@bsdimp.com> <4B9303E4.3090500@geocities.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B9303E4.3090500@geocities.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 07:00:17 -0000 On Sun, Mar 07, 2010 at 02:39:48AM +0100, Maks Verver wrote: > On 03/06/2010 10:17 PM, Bernd Walter wrote: > > Such massive speed difference sounds a bit like cache problems. > > On 03/06/2010 11:26 PM, M. Warner Losh wrote: > > Sounds a lot like ICACHE isn't being enabled, since a 3-liner like > > this should be executing entirely out of cache after the first > > instruction in main prefetches the cache line. > > Thanks for the quick responses! I think the both of you are right. I > didn't realize the cache could be turned off at all, but the boot output > shows: > > CPU: Feroceon 88FR131 rev 1 (write-through core) > WB enabled EABT branch prediction enabled > 16KB/32B 4-way Instruction cache > 16KB/32B 4-way write-back-locking-C Data cache > > This is different from the output on the wiki (which instructions I > followed, to some extent) at http://wiki.freebsd.org/FreeBSDMarvell: > > CPU: ARM926EJ-S rev 0 (ARM9EJ-S core) > DC enabled IC enabled WB enabled EABT branch prediction enabled > 32KB/32B 1-way Instruction cache > 32KB/32B 4-way write-back-locking-C Data cache > > Note that this guy is not running a SheevaPlug; the CPU is different. That's probably just because of different CPUs. I see a similar output on all of my systems with ARM920T CPU and still there is something wrong. I just verified with my 7.0-current system: [102]arm9# ./test 200.000u 3.000s 12:51.47 26.3% 45+1512k 0+0io 0pf+0w The system is productive and isn't completely idle, but the time is still smaller, so it is hard to say if there is a problem as well. Most interesting is a 8.0-current system I have: [4]beaver.cicely.de> ./test 196.000u 1.000s 3:43.03 88.8% 44+1452k 0+0io 0pf+0w Still much slower than calculated 80 seconds though, but also much faster than on my 9-current system. > But it's clear enough that on my system both processor caches are > disabled (even though they are correctly identified) and this is > understandably catastrophic for performance. It's good to have that > figured out at least. :-) Your loop isn't doing any data access, so it's just saying something about ICACHE not working. > The logical next question is: why aren't these caches enabled? How is > this supposed to work? Is the bootloader supposed to enable the cache, > or the kernel? If the kernel, why isn't it doing this? (If it's the > bootloader's task, then it's strange that the Linux kernel has no > trouble enabling the cache with the same bootloader). That's a good question. The kernel identifies them as being enabled on my CPU, but is it really true? IS there something which disables it later or this code is already wrong. But maybe it is not ICACHE itself and the memory pages are just declared uncacheable? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sun Mar 7 19:56: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 72129106566C for ; Sun, 7 Mar 2010 19:56:34 +0000 (UTC) (envelope-from maksverver@geocities.com) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.freebsd.org (Postfix) with ESMTP id DCC738FC1B for ; Sun, 7 Mar 2010 19:56:33 +0000 (UTC) Received: from heaven.student.utwente.nl (heaven.student.utwente.nl [130.89.167.52]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o27JuFC6014969 for ; Sun, 7 Mar 2010 20:56:16 +0100 Message-ID: <4B9404DE.70607@geocities.com> Date: Sun, 07 Mar 2010 20:56:14 +0100 From: Maks Verver User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100209 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <4B92BD9D.6030709@geocities.com> <20100306211715.GK58319@cicely7.cicely.de> <20100306215153.GL58319@cicely7.cicely.de> <20100306.152603.716362616846278503.imp@bsdimp.com> <4B9303E4.3090500@geocities.com> <20100307070010.GO58319@cicely7.cicely.de> In-Reply-To: <20100307070010.GO58319@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: maksverver@geocities.com X-Spam-Status: No Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 19:56:34 -0000 On 03/07/2010 08:00 AM, Bernd Walter wrote: > That's probably just because of different CPUs. > I see a similar output on all of my systems with ARM920T CPU and > still there is something wrong. That's strange indeed. I'm not sure if our problems are at all related (as in: caused by the same problem) as you seem to be using fairly different hardware. In my case the kernel (at boot up) doesn't seem to even think caches are enabled, which gives me some hope that if they were, then they would work. In your case the kernel claims to enable them but then they don't work. Seems different to me. > Your loop isn't doing any data access, so it's just saying something > about ICACHE not working. True enough. > But maybe it is not ICACHE itself and the memory pages are just > declared uncacheable? Another possibility. If anyone has suggestions on how to investigate this, I'd love to hear it. - Maks Verver. From owner-freebsd-arm@FreeBSD.ORG Sun Mar 7 20:12:29 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 ED5D1106564A for ; Sun, 7 Mar 2010 20:12:29 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 599058FC17 for ; Sun, 7 Mar 2010 20:12:28 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o27KCRlw066730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 7 Mar 2010 21:12:27 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o27KCOfO077340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Mar 2010 21:12:24 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o27KCNV7012611; Sun, 7 Mar 2010 21:12:23 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o27KCNWh012610; Sun, 7 Mar 2010 21:12:23 +0100 (CET) (envelope-from ticso) Date: Sun, 7 Mar 2010 21:12:23 +0100 From: Bernd Walter To: Maks Verver Message-ID: <20100307201222.GB11192@cicely7.cicely.de> References: <4B92BD9D.6030709@geocities.com> <20100306211715.GK58319@cicely7.cicely.de> <20100306215153.GL58319@cicely7.cicely.de> <20100306.152603.716362616846278503.imp@bsdimp.com> <4B9303E4.3090500@geocities.com> <20100307070010.GO58319@cicely7.cicely.de> <4B9404DE.70607@geocities.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B9404DE.70607@geocities.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 20:12:30 -0000 On Sun, Mar 07, 2010 at 08:56:14PM +0100, Maks Verver wrote: > On 03/07/2010 08:00 AM, Bernd Walter wrote: > > That's probably just because of different CPUs. > > I see a similar output on all of my systems with ARM920T CPU and > > still there is something wrong. > > That's strange indeed. I'm not sure if our problems are at all related > (as in: caused by the same problem) as you seem to be using fairly > different hardware. That's true, but the symptoms I see are quite similar, although the OS version seem to have an influence on how high the performance loss actually is. This fact is especially puzzling, because I would have either expected similar results or calulated performance. > In my case the kernel (at boot up) doesn't seem to even think caches are > enabled, which gives me some hope that if they were, then they would > work. In your case the kernel claims to enable them but then they don't > work. Seems different to me. It is just different code printing the details for your CPU. Take a look into sys/arm/arm/identcpu.c. There is "if xxx IC disabled else IC enabled" printing - if you see neither it is not printing from this code at all. > > Your loop isn't doing any data access, so it's just saying something > > about ICACHE not working. > > True enough. > > > But maybe it is not ICACHE itself and the memory pages are just > > declared uncacheable? > > Another possibility. If anyone has suggestions on how to investigate > this, I'd love to hear it. Me too. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sun Mar 7 20:30:59 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 0C0B81065673 for ; Sun, 7 Mar 2010 20:30:59 +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 A29DC8FC16 for ; Sun, 7 Mar 2010 20:30:58 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id A1488C42D1; Sun, 7 Mar 2010 21:33:23 +0100 (CET) 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 6QpR47zOICNi; Sun, 7 Mar 2010 21:33:23 +0100 (CET) Received: from [192.168.133.14] (nat2-133.ghnet.pl [91.150.223.133]) by smtp.semihalf.com (Postfix) with ESMTPSA id E23F1C41E7; Sun, 7 Mar 2010 21:33:22 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <4B9404DE.70607@geocities.com> Date: Sun, 7 Mar 2010 21:30:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B92BD9D.6030709@geocities.com> <20100306211715.GK58319@cicely7.cicely.de> <20100306215153.GL58319@cicely7.cicely.de> <20100306.152603.716362616846278503.imp@bsdimp.com> <4B9303E4.3090500@geocities.com> <20100307070010.GO58319@cicely7.cicely.de> <4B9404DE.70607@geocities.com> To: Maks Verver X-Mailer: Apple Mail (2.1077) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 20:30:59 -0000 On 2010-03-07, at 20:56, Maks Verver wrote: > On 03/07/2010 08:00 AM, Bernd Walter wrote: >> That's probably just because of different CPUs. >> I see a similar output on all of my systems with ARM920T CPU and >> still there is something wrong. >=20 > That's strange indeed. I'm not sure if our problems are at all related > (as in: caused by the same problem) as you seem to be using fairly > different hardware. >=20 > In my case the kernel (at boot up) doesn't seem to even think caches = are > enabled, which gives me some hope that if they were, then they would > work. In your case the kernel claims to enable them but then they = don't > work. Seems different to me. The reason there is not output about cache ena/dis-able status for the = Sheeva CPU is just a minor bug. Please try the patch below to get the = status info at boot time: Index: sys/arm/arm/identcpu.c = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --- sys/arm/arm/identcpu.c (wersja 204729) = =20 +++ sys/arm/arm/identcpu.c (kopia robocza) = =20 @@ -415,6 +415,7 @@ identify_arm_cpu(void) = =20 case CPU_CLASS_ARM9EJS: = =20 case CPU_CLASS_ARM10E: = =20 case CPU_CLASS_ARM10EJ: = =20 + case CPU_CLASS_MARVELL: = =20 case CPU_CLASS_SA1: = =20 case CPU_CLASS_XSCALE: = =20 case CPU_CLASS_ARM11J: =20 I would expect L1 caches are enabled on your system (please verify with = the above patch) and it must be some other problem. If the caches were = disabled the whole system would crawl (including networking). I also = checked on another 6281-based dev board running with caches ON and = observed the same ill effect. Rafal From owner-freebsd-arm@FreeBSD.ORG Sun Mar 7 21:25:43 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 7B0F11065670 for ; Sun, 7 Mar 2010 21:25:43 +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 21D858FC23 for ; Sun, 7 Mar 2010 21:25:42 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id o27LPgLD000969; Sun, 7 Mar 2010 15:25:42 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1267997142; bh=uxYoiIOqkidH2vWkZZBOUA4Ztr3qWKEkru/Ph+Tm+mc=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=AQiOSzTpAHH+MLuZH4X7agEikwLIENePBRBl6Lw6W7aEi/8JrF6KJ7clAt/wMKYbj lHo6JU1UYiZx4SmRV8YDhl9AEe4FWUB1Hye7xcZqN8qEQ1UQxFjWOniPsCIBTP3OBk +gpClAyqkzqhIAi97Re54sU3KDljdFyCQfF3p+y4= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id o27LPfFb000968; Sun, 7 Mar 2010 15:25:41 -0600 (CST) (envelope-from tinguely) Date: Sun, 7 Mar 2010 15:25:41 -0600 (CST) From: Mark Tinguely Message-Id: <201003072125.o27LPfFb000968@casselton.net> To: maksverver@geocities.com, raj@semihalf.com In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Sun, 07 Mar 2010 15:25:42 -0600 (CST) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 21:25:43 -0000 FreeBSD-current has kernel and user witness turned on. Witness is for locks, so it should not change the performance of a tight arithmetic loop like this. I don't know the marvell interals, and from what I tell, their technial docs require NDA. That said, many of the ARM processors also have a instruction internal cache (instruction prefetch) in addition to the instruction cache. I don't think the prefetch has an enable/disable. It looks like from the cpu identification that the the branch prediction is turned on. Branch prediction compensates for the longer pipelines. I can't see how in the tight loop how that could go astray. Thus says the ARM ARM: ARM implementations are free to choose how far ahead of the current point of execution they prefetch instructions; either a fixed or a dynamically varying number of instructions. As well as being free to choose how many instructions to prefetch, an ARM implementation can choose which possible future execution path to prefetch along. For example, after a branch instruction, it can choose to prefetch either the instruction following the branch or the instruction at the branch target. This is known as branch prediction. There are a few data dangling allocations that I would like to see closed from the multiple kernel allocation fix. *IN THEORY, IF* a page is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then it is never marked as unallocated. *IN THEORY*, if that page is used again, then we could falsely believe that page is being shared and we turn off the cache, eventhough it is not shared. http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in the Sheeva implementation. This is a theoritical observation of a side effect of the multiple kernel mapping patch that we did just before FreeBSD 8-release. --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Sun Mar 7 21:38:47 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 C73EA106566C for ; Sun, 7 Mar 2010 21:38:47 +0000 (UTC) (envelope-from maksverver@geocities.com) Received: from mx.utwente.nl (mx1.utsp.utwente.nl [130.89.2.12]) by mx1.freebsd.org (Postfix) with ESMTP id 255538FC0C for ; Sun, 7 Mar 2010 21:38:46 +0000 (UTC) Received: from heaven.student.utwente.nl (heaven.student.utwente.nl [130.89.167.52]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o27Lcdpo005592 for ; Sun, 7 Mar 2010 22:38:40 +0100 Message-ID: <4B941CDC.4010101@geocities.com> Date: Sun, 07 Mar 2010 22:38:36 +0100 From: Maks Verver User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100209 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <4B92BD9D.6030709@geocities.com> <20100306211715.GK58319@cicely7.cicely.de> <20100306215153.GL58319@cicely7.cicely.de> <20100306.152603.716362616846278503.imp@bsdimp.com> <4B9303E4.3090500@geocities.com> <20100307070010.GO58319@cicely7.cicely.de> <4B9404DE.70607@geocities.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: maksverver@geocities.com X-Spam-Status: No Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 21:38:47 -0000 On 03/07/2010 09:30 PM, Rafal Jaworowski wrote: > The reason there is not output about cache ena/dis-able status for > the Sheeva CPU is just a minor bug. Please try the patch below to get > the status info at boot time: Thanks. I figured this out myself after Bernd's last message. There is another (bigger) bug in identcpu.c though: cpu_classes[] defines only 17 entries while enum cpu_class defines 18 values, CPU_CLASS_MARVELL being the last one. Therefore, identcpu.c reads outside the cpu_classes array! (That's why I got the nonsensical "write-through core" in my output; although it's better than a crash.) I think both of these bugs should be fixed, but that doesn't help with the performance problem of course. > I would expect L1 caches are enabled on your system (please verify > with the above patch) and it must be some other problem. If the > caches were disabled the whole system would crawl (including > networking). I also checked on another 6281-based dev board running > with caches ON and observed the same ill effect. You're right. It prints that L1 data and instruction caches are on. The L2 cache bit is off, but this was to be expected, as I understand from the Linux code that the Feroceon's L2 cache is not configured through the standard system control register. So the problem must lie somewhere else then. Any suggestions where to look next? - Maks Verver. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 00:27:13 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 0A0611065672 for ; Mon, 8 Mar 2010 00:27:13 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 86FBD8FC0A for ; Mon, 8 Mar 2010 00:27:11 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o280R8s3074111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2010 01:27:08 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o280R57Z090599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 01:27:05 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o280R5wH013736; Mon, 8 Mar 2010 01:27:05 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o280R4BS013735; Mon, 8 Mar 2010 01:27:04 +0100 (CET) (envelope-from ticso) Date: Mon, 8 Mar 2010 01:27:04 +0100 From: Bernd Walter To: Mark Tinguely Message-ID: <20100308002704.GL11192@cicely7.cicely.de> References: <201003072125.o27LPfFb000968@casselton.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003072125.o27LPfFb000968@casselton.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 00:27:13 -0000 On Sun, Mar 07, 2010 at 03:25:41PM -0600, Mark Tinguely wrote: > > FreeBSD-current has kernel and user witness turned on. Witness is for > locks, so it should not change the performance of a tight arithmetic loop > like this. I have no kernel debugging enabled. I have no malloc.conf on current, but I have on the 8.0-current system, so malloc debugging is enabled on one machine, but it shouldn't hurt in this case since it is not allocating anything. > I don't know the marvell interals, and from what I tell, their technial > docs require NDA. That said, many of the ARM processors also have a > instruction internal cache (instruction prefetch) in addition to the > instruction cache. I don't think the prefetch has an enable/disable. > > It looks like from the cpu identification that the the branch prediction > is turned on. Branch prediction compensates for the longer pipelines. > I can't see how in the tight loop how that could go astray. > > Thus says the ARM ARM: > > ARM implementations are free to choose how far ahead of the > current point of execution they prefetch instructions; either > a fixed or a dynamically varying number of instructions. As well > as being free to choose how many instructions to prefetch, an ARM > implementation can choose which possible future execution path to > prefetch along. For example, after a branch instruction, it can > choose to prefetch either the instruction following the branch > or the instruction at the branch target. This is known as branch > prediction. > > There are a few data dangling allocations that I would like to see > closed from the multiple kernel allocation fix. *IN THEORY, IF* a page > is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then > it is never marked as unallocated. *IN THEORY*, if that page is used > again, then we could falsely believe that page is being shared and > we turn off the cache, eventhough it is not shared. > > http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff > > * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in > the Sheeva implementation. This is a theoritical observation of a side > effect of the multiple kernel mapping patch that we did just before > FreeBSD 8-release. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 01:31:14 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 B12CF106564A for ; Mon, 8 Mar 2010 01:31:14 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 56FAB8FC18 for ; Mon, 8 Mar 2010 01:31:13 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o281V9n4075522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2010 02:31:09 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o281V6ms092534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 02:31:06 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o281V6q8014054; Mon, 8 Mar 2010 02:31:06 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o281V55e014053; Mon, 8 Mar 2010 02:31:05 +0100 (CET) (envelope-from ticso) Date: Mon, 8 Mar 2010 02:31:05 +0100 From: Bernd Walter To: Mark Tinguely Message-ID: <20100308013105.GP11192@cicely7.cicely.de> References: <201003072125.o27LPfFb000968@casselton.net> <20100308002704.GL11192@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100308002704.GL11192@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 01:31:14 -0000 On Mon, Mar 08, 2010 at 01:27:04AM +0100, Bernd Walter wrote: > On Sun, Mar 07, 2010 at 03:25:41PM -0600, Mark Tinguely wrote: > > > > FreeBSD-current has kernel and user witness turned on. Witness is for > > locks, so it should not change the performance of a tight arithmetic loop > > like this. > > I have no kernel debugging enabled. > I have no malloc.conf on current, but I have on the 8.0-current system, > so malloc debugging is enabled on one machine, but it shouldn't hurt in > this case since it is not allocating anything. > > > I don't know the marvell interals, and from what I tell, their technial > > docs require NDA. That said, many of the ARM processors also have a > > instruction internal cache (instruction prefetch) in addition to the > > instruction cache. I don't think the prefetch has an enable/disable. > > > > It looks like from the cpu identification that the the branch prediction > > is turned on. Branch prediction compensates for the longer pipelines. > > I can't see how in the tight loop how that could go astray. > > > > Thus says the ARM ARM: > > > > ARM implementations are free to choose how far ahead of the > > current point of execution they prefetch instructions; either > > a fixed or a dynamically varying number of instructions. As well > > as being free to choose how many instructions to prefetch, an ARM > > implementation can choose which possible future execution path to > > prefetch along. For example, after a branch instruction, it can > > choose to prefetch either the instruction following the branch > > or the instruction at the branch target. This is known as branch > > prediction. > > > > There are a few data dangling allocations that I would like to see > > closed from the multiple kernel allocation fix. *IN THEORY, IF* a page > > is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then > > it is never marked as unallocated. *IN THEORY*, if that page is used > > again, then we could falsely believe that page is being shared and > > we turn off the cache, eventhough it is not shared. > > > > http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff > > > > * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in > > the Sheeva implementation. This is a theoritical observation of a side > > effect of the multiple kernel mapping patch that we did just before > > FreeBSD 8-release. This sounds possible. My 8.0-current system should be before that change and it is much faster than my current system. It is still slower than the calculated ~80s and the difference looks a bit large to just think it is a stalled pipeline because of the branch. Has anyone access to a RM9200 system running Linux? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 02:16:51 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 0CAB11065673 for ; Mon, 8 Mar 2010 02:16:51 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8DC318FC16 for ; Mon, 8 Mar 2010 02:16:50 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o282Gj23076897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2010 03:16:46 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o282GgQo096116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 03:16:42 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o282GgnY014523; Mon, 8 Mar 2010 03:16:42 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o282GgqM014522; Mon, 8 Mar 2010 03:16:42 +0100 (CET) (envelope-from ticso) Date: Mon, 8 Mar 2010 03:16:42 +0100 From: Bernd Walter To: Mark Tinguely Message-ID: <20100308021642.GQ11192@cicely7.cicely.de> References: <201003072125.o27LPfFb000968@casselton.net> <20100308002704.GL11192@cicely7.cicely.de> <20100308013105.GP11192@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100308013105.GP11192@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 02:16:51 -0000 On Mon, Mar 08, 2010 at 02:31:05AM +0100, Bernd Walter wrote: > On Mon, Mar 08, 2010 at 01:27:04AM +0100, Bernd Walter wrote: > > On Sun, Mar 07, 2010 at 03:25:41PM -0600, Mark Tinguely wrote: > > > > > > FreeBSD-current has kernel and user witness turned on. Witness is for > > > locks, so it should not change the performance of a tight arithmetic loop > > > like this. > > > > I have no kernel debugging enabled. > > I have no malloc.conf on current, but I have on the 8.0-current system, > > so malloc debugging is enabled on one machine, but it shouldn't hurt in > > this case since it is not allocating anything. > > > > > I don't know the marvell interals, and from what I tell, their technial > > > docs require NDA. That said, many of the ARM processors also have a > > > instruction internal cache (instruction prefetch) in addition to the > > > instruction cache. I don't think the prefetch has an enable/disable. > > > > > > It looks like from the cpu identification that the the branch prediction > > > is turned on. Branch prediction compensates for the longer pipelines. > > > I can't see how in the tight loop how that could go astray. > > > > > > Thus says the ARM ARM: > > > > > > ARM implementations are free to choose how far ahead of the > > > current point of execution they prefetch instructions; either > > > a fixed or a dynamically varying number of instructions. As well > > > as being free to choose how many instructions to prefetch, an ARM > > > implementation can choose which possible future execution path to > > > prefetch along. For example, after a branch instruction, it can > > > choose to prefetch either the instruction following the branch > > > or the instruction at the branch target. This is known as branch > > > prediction. > > > > > > There are a few data dangling allocations that I would like to see > > > closed from the multiple kernel allocation fix. *IN THEORY, IF* a page > > > is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then > > > it is never marked as unallocated. *IN THEORY*, if that page is used > > > again, then we could falsely believe that page is being shared and > > > we turn off the cache, eventhough it is not shared. > > > > > > http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff > > > > > > * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in > > > the Sheeva implementation. This is a theoritical observation of a side > > > effect of the multiple kernel mapping patch that we did just before > > > FreeBSD 8-release. > > This sounds possible. > My 8.0-current system should be before that change and it is much faster > than my current system. > It is still slower than the calculated ~80s and the difference looks > a bit large to just think it is a stalled pipeline because of the branch. > Has anyone access to a RM9200 system running Linux? With your patch my current system is faster as well. [55]chipmunk.cicely.de# ./test 207.000u 0.000s 4:01.13 86.0% 46+1516k 0+0io 0pf+0w [56]chipmunk.cicely.de# ./test 207.000u 0.000s 3:55.66 87.9% 45+1516k 0+0io 0pf+0w It is still puzzling me why it is not near 80 seconds. This would mean it is loosing something about 5-6 cycles. Well - Ok - the pipeline might be that long and real loops are mostly some instructions longer. But I would still be interested to see Linux results on RM9200. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 03:00:06 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 215AF106566B for ; Mon, 8 Mar 2010 03:00:06 +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 C4FF88FC12 for ; Mon, 8 Mar 2010 03:00:05 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id o28303nB011299; Sun, 7 Mar 2010 21:00:03 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1268017203; bh=YU91a4NdBx7M28HnX+gdO2ZSe87T9dkbR7A2I44OOqM=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=JDcdUy/TvzhBUOBRtusN53LYuP0y9JJB/6XPMLm3HCesdMMQNTDJ+Ttsnzal8i6wA DqsYXeGXJGIL68BenSvkXRBeqIQo90Z06pzeHryKPH2H2PgV/XCcHskHtzXjACmIrJ eTa7KMLLfO77U0yFuHwMQB6WRQfU6Mt3WAFSXUO0= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id o28303CD011298; Sun, 7 Mar 2010 21:00:03 -0600 (CST) (envelope-from tinguely) Date: Sun, 7 Mar 2010 21:00:03 -0600 (CST) From: Mark Tinguely Message-Id: <201003080300.o28303CD011298@casselton.net> To: ticso@cicely.de In-Reply-To: <20100308021642.GQ11192@cicely7.cicely.de> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Sun, 07 Mar 2010 21:00:03 -0600 (CST) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 03:00:06 -0000 > It is still puzzling me why it is not near 80 seconds. > This would mean it is loosing something about 5-6 cycles. > Well - Ok - the pipeline might be that long and real loops are > mostly some instructions longer. > But I would still be interested to see Linux results on RM9200. > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. Thinking way out of the box ... has anyone tried this in single user mode? --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 04:11:09 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 06F9F1065672 for ; Mon, 8 Mar 2010 04:11:09 +0000 (UTC) (envelope-from lists@walkertc.com) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by mx1.freebsd.org (Postfix) with SMTP id 8F67D8FC0A for ; Mon, 8 Mar 2010 04:11:08 +0000 (UTC) Received: (qmail 29906 invoked from network); 8 Mar 2010 03:44:28 -0000 Received: from hellfire (lists@76.99.16.166 with login) by smtp114.biz.mail.re2.yahoo.com with SMTP; 07 Mar 2010 19:44:28 -0800 PST X-Yahoo-SMTP: uCeTjDGswBCELW0sgK7G6dZF2tzjB86bk4G5h4OmJw-- X-YMail-OSG: FqAQpNcVM1nDJ2bdnOkdA_DAXaWN5NEm.BAR6.9gDAJQuADqhyV7obXPPgOq8nK3rgzsPbh6gczcPF081odsDwmyzag3sNOnavUP3xHioE_4xTcqtj8cITIGNDcrm1Ljp00v_X.imRNg5lwL8mRqFXO6grQtYOQel1seylCutWTeVONe4IdQyZRkUgoDisXO9HjRkaBTqHeWhDc_3x3tXtg7kMfu5Vz75bNErSF3NftFNeBiAMWN0S0OsI1sQ0EIq6GfuLXVlSqzSVmeXxWblENrro7M8BVsYi7E96tBBaCOBMUTirmcQedo9VWVQ9CctI59HgtSY3GX1iSAig8CzB35qAk. X-Yahoo-Newman-Property: ymail-3 From: To: Date: Sun, 7 Mar 2010 22:44:30 -0500 Message-ID: <000201cabe71$a8f830a0$fae891e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq+caSQnoaRx+tTQ4W3rkQGY9QLMw== Content-Language: en-us x-cr-hashedpuzzle: /vw= ATUJ Bn55 CySt Eitg FNpA FsxJ GVw5 HU5v IRit IT9y ItTQ IvTR I/jQ KW4V K/MO; 1; ZgByAGUAZQBiAHMAZAAtAGEAcgBtAEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnAA==; Sosha1_v1; 7; {BE705548-C5EE-40D0-9A0F-C611CA245D00}; bABpAHMAdABzAEAAdwBhAGwAawBlAHIAdABjAC4AYwBvAG0A; Mon, 08 Mar 2010 03:44:28 GMT; UwBtAGEAbABsAGUAcwB0ACAAQQBSAE0AIABEAGUAdgBpAGMAZQAgAGYAbwByACAARgByAGUAZQBCAFMARAA= x-cr-puzzleid: {BE705548-C5EE-40D0-9A0F-C611CA245D00} Subject: Smallest ARM Device for FreeBSD 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, 08 Mar 2010 04:11:09 -0000 What is the smallest ARM device that FreeBSD can run on? I am also looking for recommendations with respect to the most compatible ARM device that works with FreeBSD - and possibly the tradeoffs between devices. The web site doesn't go into much detail. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 08:20:56 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 4DAFF1065670 for ; Mon, 8 Mar 2010 08:20:56 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id C8EC68FC0C for ; Mon, 8 Mar 2010 08:20:55 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o288Kot6087089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2010 09:20:50 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o288Kh3Y008482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 09:20:43 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o288Khnc016293; Mon, 8 Mar 2010 09:20:43 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o288KhFZ016292; Mon, 8 Mar 2010 09:20:43 +0100 (CET) (envelope-from ticso) Date: Mon, 8 Mar 2010 09:20:43 +0100 From: Bernd Walter To: Mark Tinguely Message-ID: <20100308082043.GT11192@cicely7.cicely.de> References: <20100308021642.GQ11192@cicely7.cicely.de> <201003080300.o28303CD011298@casselton.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003080300.o28303CD011298@casselton.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@freebsd.org, ticso@cicely.de Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 08:20:56 -0000 On Sun, Mar 07, 2010 at 09:00:03PM -0600, Mark Tinguely wrote: > > > > > It is still puzzling me why it is not near 80 seconds. > > This would mean it is loosing something about 5-6 cycles. > > Well - Ok - the pipeline might be that long and real loops are > > mostly some instructions longer. > > But I would still be interested to see Linux results on RM9200. > > Thinking way out of the box ... has anyone tried this in single user mode? Would be difficult for me since I have no loader to submit bootflags. Loader support is definitiv on my wishlist, but that's a another subject. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 08:26:01 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 73629106564A for ; Mon, 8 Mar 2010 08:26:01 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0CBEE8FC14 for ; Mon, 8 Mar 2010 08:26:00 +0000 (UTC) Received: by wwb17 with SMTP id 17so3265483wwb.13 for ; Mon, 08 Mar 2010 00:25:59 -0800 (PST) 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=KtnLJGATXS/weJIcmaPorUv53mYreI4ZBT7Hxpl4Sqk=; b=Qbt59dDidT66Yd5IXrTsbbHoRhUKN44YMkmphL6yrdl0t08kcRx5GRb4qX4lJssxtR NlpcTkW/iN0F0eOubTeq85Ln1wMXK5loBwDtQbkF7LgC1BmFj+j3hjyLjpZudBtEaIFs KETyxmgqjPp6z+pY1whiAZjWXNmEJ4qO26NUI= 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=x2kZh2n8G075b11BENOHs72TzX+iJ0rCCRuGu1h4/poIPXI2iA48SS949QY0sdzp+V HZNfIAmSjg+r8ePe6+APMj8UEutB8+XmpH2Y8Rqi9B9328+E6k4iQpi0HKYYZx2W8OWB kNCd5VytB2VfeP1YMoHzzjfRyx9cBXmVQFoLk= MIME-Version: 1.0 Received: by 10.216.85.17 with SMTP id t17mr1344896wee.178.1268036759754; Mon, 08 Mar 2010 00:25:59 -0800 (PST) In-Reply-To: <201003080300.o28303CD011298@casselton.net> References: <20100308021642.GQ11192@cicely7.cicely.de> <201003080300.o28303CD011298@casselton.net> Date: Mon, 8 Mar 2010 10:25:59 +0200 Message-ID: From: Jacques Fourie To: Mark Tinguely Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org, ticso@cicely.de Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 08:26:01 -0000 On Mon, Mar 8, 2010 at 5:00 AM, Mark Tinguely wrot= e: > > > >> =A0It is still puzzling me why it is not near 80 seconds. >> =A0This would mean it is loosing something about 5-6 cycles. >> =A0Well - Ok - the pipeline might be that long and real loops are >> =A0mostly some instructions longer. >> =A0But I would still be interested to see Linux results on RM9200. >> >> =A0-- >> =A0B.Walter http://www.bwct.de >> =A0Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > > > Thinking way out of the box ... has anyone tried this in single user mode= ? > > --Mark Tinguely > _______________________________________________ > 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" > The xscale platforms now have hwpmc(4) support, maybe this will help in tracking down this issue? From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 09:08: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 2A6A0106564A for ; Mon, 8 Mar 2010 09:08:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.swip.net [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id A9C028FC08 for ; Mon, 8 Mar 2010 09:08:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=VWuzlhLQqxAA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=o0zQbiD9AAAA:8 a=0m7h8hzpAAAA:8 a=lNieZC5AVUH5js7iDtwA:9 a=Gb1nk_8o6g-gcYINcyWhzY-yfi4A:4 a=wPNLvfGTeEIA:10 a=13CKhUYk-dQA:10 a=Fb4p3Z96-coA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 637026488; Mon, 08 Mar 2010 10:08:49 +0100 From: Hans Petter Selasky To: freebsd-arm@freebsd.org Date: Mon, 8 Mar 2010 10:07:14 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <20100308021642.GQ11192@cicely7.cicely.de> <201003080300.o28303CD011298@casselton.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003081007.14326.hselasky@c2i.net> Cc: Mark Tinguely , ticso@cicely.de Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 09:08:52 -0000 On Monday 08 March 2010 09:25:59 Jacques Fourie wrote: > On Mon, Mar 8, 2010 at 5:00 AM, Mark Tinguely wrote: > > > > > >> It is still puzzling me why it is not near 80 seconds. > >> This would mean it is loosing something about 5-6 cycles. > >> Well - Ok - the pipeline might be that long and real loops are > >> mostly some instructions longer. > >> But I would still be interested to see Linux results on RM9200. > >> > >> -- > >> B.Walter http://www.bwct.de > >> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > > > > Thinking way out of the box ... has anyone tried this in single user > > mode? > > Was the output from "vmstat -i" and "top" posted? --HPS From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 11:06:56 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 2BF7110656B5 for ; Mon, 8 Mar 2010 11:06:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 70B6A8FC17 for ; Mon, 8 Mar 2010 11:06:53 +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 o28B6rah073627 for ; Mon, 8 Mar 2010 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o28B6qdu073625 for freebsd-arm@FreeBSD.org; Mon, 8 Mar 2010 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Mar 2010 11:06:52 GMT Message-Id: <201003081106.o28B6qdu073625@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, 08 Mar 2010 11:06:56 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/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 Mar 8 12:28:40 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 5B5A2106567B for ; Mon, 8 Mar 2010 12:28:40 +0000 (UTC) (envelope-from batcilla@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id E4C278FC08 for ; Mon, 8 Mar 2010 12:28:39 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so914304fge.13 for ; Mon, 08 Mar 2010 04:28:38 -0800 (PST) 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; bh=2E8tNB2ClvB0+7Dp4gIJ0bQQ45S82YCNj5KSdqx6V/I=; b=eCQOzrROwfqfBl+ww4FsGT1ao3HpIRob25QZNvc7+MHvSzne25i3P3t0ryhKLrzlhY uh6LAi7pfeUtNk8fS7OqAituM+zfQTFxsHbkHR9qGRk1sfT4ZHlAYZPROEH9FDyojDNz PvC5k3MeknJVshqz7rjdcUqHoU7OZbO1+p3tc= 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=XOxz0soli0w3Dw+cLzfA8RYx4PXKQLX5UHyBa3SuofknRQxG73EnpBu7P7NGCpT4di lxJzU22CJLwSf80WgbotjMZgGR5naZKMEE77D4qc4bmhSdxY1T2vSc8ElgUiCPpDIW8r c7NQh+yFqs0Etf/CqHM50K3TvBrLp+VUESLec= MIME-Version: 1.0 Received: by 10.239.187.139 with SMTP id l11mr382145hbh.96.1268051318578; Mon, 08 Mar 2010 04:28:38 -0800 (PST) In-Reply-To: <000201cabe71$a8f830a0$fae891e0$@com> References: <000201cabe71$a8f830a0$fae891e0$@com> Date: Mon, 8 Mar 2010 14:28:38 +0200 Message-ID: <6c36ec371003080428p54206f8t9356c999675c0933@mail.gmail.com> From: batcilla itself To: lists@walkertc.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arm@freebsd.org Subject: Re: Smallest ARM Device for FreeBSD 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, 08 Mar 2010 12:28:40 -0000 Is depends - which features you need? I believe FreeBSD 8 or -current can be run on most 10x10cm ARM Xscale boards, but only kernel and very minimal md rootfs. Also you may need to port some i2c stuff and fix IRQ->GPIO etc. //batcilla 2010/3/8 > What is the smallest ARM device that FreeBSD can run on? > > I am also looking for recommendations with respect to the most compatible > ARM device that works with FreeBSD - and possibly the tradeoffs between > devices. The web site doesn't go into much detail. > > > _______________________________________________ > 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 Mar 8 12:41:30 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 A58CE106564A for ; Mon, 8 Mar 2010 12:41:30 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 127928FC0C for ; Mon, 8 Mar 2010 12:41:29 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o28CfLjn007774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2010 13:41:22 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o28CfIkv017195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 13:41:18 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o28CfIe4017365; Mon, 8 Mar 2010 13:41:18 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o28CfH7S017364; Mon, 8 Mar 2010 13:41:17 +0100 (CET) (envelope-from ticso) Date: Mon, 8 Mar 2010 13:41:17 +0100 From: Bernd Walter To: Hans Petter Selasky Message-ID: <20100308124117.GW11192@cicely7.cicely.de> References: <20100308021642.GQ11192@cicely7.cicely.de> <201003080300.o28303CD011298@casselton.net> <201003081007.14326.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003081007.14326.hselasky@c2i.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@freebsd.org, Mark Tinguely , ticso@cicely.de Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 12:41:30 -0000 On Mon, Mar 08, 2010 at 10:07:14AM +0100, Hans Petter Selasky wrote: > On Monday 08 March 2010 09:25:59 Jacques Fourie wrote: > > On Mon, Mar 8, 2010 at 5:00 AM, Mark Tinguely > wrote: > > > > > > > > >> It is still puzzling me why it is not near 80 seconds. > > >> This would mean it is loosing something about 5-6 cycles. > > >> Well - Ok - the pipeline might be that long and real loops are > > >> mostly some instructions longer. > > >> But I would still be interested to see Linux results on RM9200. > > >> > > >> -- > > >> B.Walter http://www.bwct.de > > >> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > > > > > > Thinking way out of the box ... has anyone tried this in single user > > > mode? > > > > > Was the output from "vmstat -i" and "top" posted? No, but I can say that my current and 8.0-current system had almost no load. My 7.0-current system had about 60-70% load and was about 3 times slower than the 8.0 and the patched 9.0 system, so it makes sense. Do you expect anything special to see? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 13:40:54 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 02E67106564A for ; Mon, 8 Mar 2010 13:40:54 +0000 (UTC) (envelope-from lists@walkertc.com) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by mx1.freebsd.org (Postfix) with SMTP id 898908FC08 for ; Mon, 8 Mar 2010 13:40:53 +0000 (UTC) Received: (qmail 67565 invoked from network); 8 Mar 2010 13:40:52 -0000 Received: from hellfire (lists@76.99.16.166 with login) by smtp114.biz.mail.re2.yahoo.com with SMTP; 08 Mar 2010 05:40:52 -0800 PST X-Yahoo-SMTP: uCeTjDGswBCELW0sgK7G6dZF2tzjB86bk4G5h4OmJw-- X-YMail-OSG: cxkBMD8VM1kfhzP8dts01aE4ACLNJvRtyfbNzVENin777DBIZO_ns_OG0dpTz3X4PkdetvylgvGNn5AGLSdlq5BLgKl34X9E1xkb5WZNAZb0E0NtZ7x.2CI3i8itbp_HpiK0uhzBr7z96FNyjShSCCxEy2ES9tvekpCD0wxQPxoyr1XlhRJqarWXsHJ.Bx2nSMKzWXJprnSg5lf2F3ckUYDbPlZfH6JFHjTFLAJoP4ESuRogpDotIKkY1mr3XyoKzaq0I.N6zme0LlpUo9etbd.kuYyt4mGq0IKc4AB6qcPO_Ml1q8Reg7xY9xCspea7vpd5HKaKy2lb7bX0W8aE3jEnr7b_OEtHihbkDZ3jVn4nC869WdKhPmaKTQIxISOsrA-- X-Yahoo-Newman-Property: ymail-3 From: To: References: <000201cabe71$a8f830a0$fae891e0$@com> <6c36ec371003080428p54206f8t9356c999675c0933@mail.gmail.com> In-Reply-To: <6c36ec371003080428p54206f8t9356c999675c0933@mail.gmail.com> Date: Mon, 8 Mar 2010 08:40:52 -0500 Message-ID: <000c01cabec4$f8758800$e9609800$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq+uuGALLBK+PwGQIG6DQ/BGuTq8gABu8Nw Content-Language: en-us Subject: RE: Smallest ARM Device for FreeBSD 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, 08 Mar 2010 13:40:54 -0000 This will be a minimal system that really only needs 2 USB or serial inputs and network connectivity. It will act as a "sensor" - serving to read from the 2 inputs and relaying that information over the network. I'm actually flexible enough to not even have the 2 inputs since shrinking the system takes a higher priority. -----Original Message----- From: batcilla itself [mailto:batcilla@gmail.com] Sent: Monday, March 08, 2010 7:29 AM To: lists@walkertc.com Cc: freebsd-arm@freebsd.org Subject: Re: Smallest ARM Device for FreeBSD Is depends - which features you need? I believe FreeBSD 8 or -current can be run on most 10x10cm ARM Xscale boards, but only kernel and very minimal md rootfs. Also you may need to port some i2c stuff and fix IRQ->GPIO etc. //batcill From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 13:57:58 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 71AAD106566C for ; Mon, 8 Mar 2010 13:57:58 +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 167A78FC15 for ; Mon, 8 Mar 2010 13:57:57 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id o28DvswF030993; Mon, 8 Mar 2010 07:57:54 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1268056674; bh=pXx+UOAXexxh3DFOa139tinn+pYmjAaUBrJyxovTE9k=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=UNItuR0yigtK9wGfkLfv9r/x4pDju+IUWhuuZdXfZJS6+gooIZNxiSXHcJljYB5em lRkgZdexNA+x/j2tvktwWTHwH3CxvSM60+pMUZ4XD8ZOGvrxcam2rUYtYP75Gic4l3 wC/zCJe9uqLEdL6RspgMxFIwaIn94Zs4Y1Kz7zHc= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id o28Dvs1K030992; Mon, 8 Mar 2010 07:57:54 -0600 (CST) (envelope-from tinguely) Date: Mon, 8 Mar 2010 07:57:54 -0600 (CST) From: Mark Tinguely Message-Id: <201003081357.o28Dvs1K030992@casselton.net> To: ticso@cicely.de In-Reply-To: <20100308124117.GW11192@cicely7.cicely.de> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Mon, 08 Mar 2010 07:57:54 -0600 (CST) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 13:57:58 -0000 > On Mon, Mar 08, 2010 at 10:07:14AM +0100, Hans Petter Selasky wrote: > > On Monday 08 March 2010 09:25:59 Jacques Fourie wrote: > > > On Mon, Mar 8, 2010 at 5:00 AM, Mark Tinguely > > wrote: > > > > > > > > > > > >> It is still puzzling me why it is not near 80 seconds. > > > >> This would mean it is loosing something about 5-6 cycles. > > > >> Well - Ok - the pipeline might be that long and real loops are > > > >> mostly some instructions longer. > > > >> But I would still be interested to see Linux results on RM9200. > > > >> > > > >> -- > > > >> B.Walter http://www.bwct.de > > > >> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > > > > > > > > Thinking way out of the box ... has anyone tried this in single user > > > > mode? > > > > > > > > Was the output from "vmstat -i" and "top" posted? > > No, but I can say that my current and 8.0-current system had almost no > load. > My 7.0-current system had about 60-70% load and was about 3 times slower > than the 8.0 and the patched 9.0 system, so it makes sense. > Do you expect anything special to see? > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > The process is in a tight CPU bound loop. I am thinking that there is still the interrupt handler (short assembly), find the next interrupt routine (typically a bitmap shift loop), clock interrupt handler, scheduler, cpu_switch() (even if it is just to the same process) that goes off every 1/HZ seconds. I would think that if there is an inefficiency in the above loop, the times should be the same magnitude in single-user as in multi-using. If you cannot go to single user then the 'vmstat -i' and 'top' is a good idea - make sure something else is not causing a context switch which would flush our caches. The performance counter idea is a good one too. Wildly grasping, here: I suppose you could run the program with time and use the wall clock or "date; a.out; date" to eliminate some problem in the "time" command. --Mark. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 14:15:46 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 3CA2F106567B for ; Mon, 8 Mar 2010 14:15:46 +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 D4DA78FC1A for ; Mon, 8 Mar 2010 14:15:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o28E7FqK081090; Mon, 8 Mar 2010 07:07:15 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 08 Mar 2010 07:07:39 -0700 (MST) Message-Id: <20100308.070739.1102829375853659343.imp@bsdimp.com> To: tinguely@casselton.net From: "M. Warner Losh" In-Reply-To: <201003081357.o28Dvs1K030992@casselton.net> References: <20100308124117.GW11192@cicely7.cicely.de> <201003081357.o28Dvs1K030992@casselton.net> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, ticso@cicely.de Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 14:15:46 -0000 In message: <201003081357.o28Dvs1K030992@casselton.net> Mark Tinguely writes: : : > On Mon, Mar 08, 2010 at 10:07:14AM +0100, Hans Petter Selasky wrote: : > > On Monday 08 March 2010 09:25:59 Jacques Fourie wrote: : > > > On Mon, Mar 8, 2010 at 5:00 AM, Mark Tinguely : > > wrote: : > > > > : > > > > : > > > >> It is still puzzling me why it is not near 80 seconds. : > > > >> This would mean it is loosing something about 5-6 cycles. : > > > >> Well - Ok - the pipeline might be that long and real loops are : > > > >> mostly some instructions longer. : > > > >> But I would still be interested to see Linux results on RM9200. : > > > >> : > > > >> -- : > > > >> B.Walter http://www.bwct.de : > > > >> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. : > > > > : > > > > Thinking way out of the box ... has anyone tried this in single user : > > > > mode? : > > > > : > > : > > Was the output from "vmstat -i" and "top" posted? : > : > No, but I can say that my current and 8.0-current system had almost no : > load. : > My 7.0-current system had about 60-70% load and was about 3 times slower : > than the 8.0 and the patched 9.0 system, so it makes sense. : > Do you expect anything special to see? : > : > -- : > B.Walter http://www.bwct.de : > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. : > : : The process is in a tight CPU bound loop. I am thinking that there is : still the interrupt handler (short assembly), find the next interrupt routine : (typically a bitmap shift loop), clock interrupt handler, scheduler, : cpu_switch() (even if it is just to the same process) that goes off every : 1/HZ seconds. I would think that if there is an inefficiency in the above : loop, the times should be the same magnitude in single-user as in multi-using. : : If you cannot go to single user then the 'vmstat -i' and 'top' is a good : idea - make sure something else is not causing a context switch which would : flush our caches. : : The performance counter idea is a good one too. : : Wildly grasping, here: : I suppose you could run the program with time and use the wall clock : or "date; a.out; date" to eliminate some problem in the "time" command. ntpdate might help here to eliminate any local clock effects.. Warner From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 14:24:16 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 362A81065674 for ; Mon, 8 Mar 2010 14:24:16 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id B18DE8FC14 for ; Mon, 8 Mar 2010 14:24:15 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o28EODEV012770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2010 15:24:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o28EO7BG020872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 15:24:07 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o28EO7Fw017824; Mon, 8 Mar 2010 15:24:07 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o28EO7Ix017823; Mon, 8 Mar 2010 15:24:07 +0100 (CET) (envelope-from ticso) Date: Mon, 8 Mar 2010 15:24:07 +0100 From: Bernd Walter To: lists@walkertc.com Message-ID: <20100308142407.GY11192@cicely7.cicely.de> References: <000201cabe71$a8f830a0$fae891e0$@com> <6c36ec371003080428p54206f8t9356c999675c0933@mail.gmail.com> <000c01cabec4$f8758800$e9609800$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000c01cabec4$f8758800$e9609800$@com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: Smallest ARM Device for FreeBSD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 14:24:16 -0000 On Mon, Mar 08, 2010 at 08:40:52AM -0500, lists@walkertc.com wrote: > This will be a minimal system that really only needs 2 USB or serial inputs > and network connectivity. It will act as a "sensor" - serving to read from > the 2 inputs and relaying that information over the network. > > I'm actually flexible enough to not even have the 2 inputs since shrinking > the system takes a higher priority. It is hard to say without knowing your design limitations about RAM, size, speed, power. My RM9200 boards have 10x10cm, 4 port ethernet switch, 64-128MB RAM and power consumption of 1.5-2.6W. It has a few GPIO - especially the RX/TX of the 4 USART as TTL and an I2C header, but it has only one USB port. There are smaller RM9200 boards with just a single RAM chip, which usually results in lower speed and without a switch. If you want more power and you have access to grid power a sheva plug can also be a nice alternative. On the other hand - I personally often use much smaller ARM7 with an embedded IP stack instead of a full featured FreeBSD system. Those systems can be even smaller since they don't need large SDRAM chips and the controllers are physically smaller as well. > -----Original Message----- > From: batcilla itself [mailto:batcilla@gmail.com] > Sent: Monday, March 08, 2010 7:29 AM > To: lists@walkertc.com > Cc: freebsd-arm@freebsd.org > Subject: Re: Smallest ARM Device for FreeBSD > > Is depends - which features you need? > I believe FreeBSD 8 or -current can be run on most 10x10cm ARM Xscale > boards, but only kernel and very minimal md rootfs. > Also you may need to port some i2c stuff and fix IRQ->GPIO etc. > > //batcill > > > _______________________________________________ > 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" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 14:29:36 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 D1EC5106566B for ; Mon, 8 Mar 2010 14:29:36 +0000 (UTC) (envelope-from maksverver@geocities.com) Received: from mx.utwente.nl (mx3.utsp.utwente.nl [130.89.2.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2AE8F8FC0A for ; Mon, 8 Mar 2010 14:29:35 +0000 (UTC) Received: from heaven.student.utwente.nl (heaven.student.utwente.nl [130.89.167.52]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o28ETRHH017262 for ; Mon, 8 Mar 2010 15:29:27 +0100 Message-ID: <4B9509C5.7050804@geocities.com> Date: Mon, 08 Mar 2010 15:29:25 +0100 From: Maks Verver User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100308 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <201003072125.o27LPfFb000968@casselton.net> In-Reply-To: <201003072125.o27LPfFb000968@casselton.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-SpamScore: s X-UTwente-MailScanner-From: maksverver@geocities.com X-Spam-Status: No Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 14:29:36 -0000 On 03/07/2010 10:25 PM, Mark Tinguely wrote: > FreeBSD-current has kernel and user witness turned on. Witness is > for locks, so it should not change the performance of a tight > arithmetic loop like this. For the record, I've been using 8-stable so far. > I don't know the marvell interals, and from what I tell, their > technial docs require NDA. Yeah, that sucks. But I don't think the SheevaPlug contains a lot of novel technology; it's just a slightly different configuration. In any case, Linux seem to have more or less complete support for the SheevaPlug (including L2 cache, SDIO and NAND flash) so for details, the GPL'ed Linux source code may be helpful. > It looks like from the cpu identification that the the branch > prediction is turned on. Branch prediction compensates for the longer > pipelines. I can't see how in the tight loop how that could go > astray. Well, since the Linux version of the test program runs exactly as well as I expect (or could ever hope for) I don't have any doubts that the CPU is able to run the tight loop efficiently. The question (for me) is why it doesn't run just as well on FreeBSD. I tried a couple of the suggestions: Mark Tingely wrote: > Thinking way out of the box ... has anyone tried this in single user > mode? I did, and it still takes 287 seconds (same as before). Petter Selasky wrote: > Was the output from "vmstat -i" and "top" posted? Note yet. vmstat -i reports: interrupt total rate irq1: timer0 130981 999 irq33: uart0 477 3 irq19: ehci0 875 6 Total 132333 1010 Which looks entirely reasonable to me. Top contains the same info as the time data I posted: 99.x% of CPU time is spent in user-mode, lots of free memory. So it seems the kernel has very little do with this. Next up, this patch: > http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff No idea what this does, but it helps a lot: %time ./test 9.000u 0.000s 0:09.11 99.2% 40+1324k 0+0io 0pf+0w That's much better than the 280+ seconds from before. But it's still nearly twice as long as Linux takes. There is more weirdness though. If I freshly boot the system I get timings like these, and even nbench reports decent scores. However, if I do a couple things like rerun/recompile nbench, then at some point something 'breaks' and the performance goes back down to what it used to be. So Mark's patch definitely touches on something related to the problem, but doesn't quite solve the problem completely. I still have no clue what's going on, but I'm willing to try out suggestions if anyone has them. :-) - Maks Verver. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 15:51:01 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 472081065675 for ; Mon, 8 Mar 2010 15:51:01 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id A84248FC14 for ; Mon, 8 Mar 2010 15:51:00 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id C2F3DC42D1; Mon, 8 Mar 2010 16:53:26 +0100 (CET) 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 4G-wvvG+l+IR; Mon, 8 Mar 2010 16:53:26 +0100 (CET) Received: from [10.0.0.75] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPA id E724AC41E7; Mon, 8 Mar 2010 16:53:25 +0100 (CET) Message-ID: <4B951CE2.6040507@semihalf.com> Date: Mon, 08 Mar 2010 16:50:58 +0100 From: Grzegorz Bernacki User-Agent: Thunderbird 2.0.0.16 (X11/20090618) MIME-Version: 1.0 To: Mark Tinguely References: <201003072125.o27LPfFb000968@casselton.net> In-Reply-To: <201003072125.o27LPfFb000968@casselton.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:51:01 -0000 Mark Tinguely wrote: > FreeBSD-current has kernel and user witness turned on. Witness is for > locks, so it should not change the performance of a tight arithmetic loop > like this. > > I don't know the marvell interals, and from what I tell, their technial > docs require NDA. That said, many of the ARM processors also have a > instruction internal cache (instruction prefetch) in addition to the > instruction cache. I don't think the prefetch has an enable/disable. > > It looks like from the cpu identification that the the branch prediction > is turned on. Branch prediction compensates for the longer pipelines. > I can't see how in the tight loop how that could go astray. > > Thus says the ARM ARM: > > ARM implementations are free to choose how far ahead of the > current point of execution they prefetch instructions; either > a fixed or a dynamically varying number of instructions. As well > as being free to choose how many instructions to prefetch, an ARM > implementation can choose which possible future execution path to > prefetch along. For example, after a branch instruction, it can > choose to prefetch either the instruction following the branch > or the instruction at the branch target. This is known as branch > prediction. > > There are a few data dangling allocations that I would like to see > closed from the multiple kernel allocation fix. *IN THEORY, IF* a page > is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then > it is never marked as unallocated. *IN THEORY*, if that page is used > again, then we could falsely believe that page is being shared and > we turn off the cache, eventhough it is not shared. > > http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff > > * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in > the Sheeva implementation. This is a theoritical observation of a side > effect of the multiple kernel mapping patch that we did just before > FreeBSD 8-release. > > --Mark Tinguely 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 From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 16:23:18 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 5FE551065670 for ; Mon, 8 Mar 2010 16:23:18 +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 1FC968FC12 for ; Mon, 8 Mar 2010 16:23:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o28GEpiU082496; Mon, 8 Mar 2010 09:14:52 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 08 Mar 2010 09:15:16 -0700 (MST) Message-Id: <20100308.091516.295937982770284454.imp@bsdimp.com> To: gjb@semihalf.com From: "M. Warner Losh" In-Reply-To: <4B951CE2.6040507@semihalf.com> References: <201003072125.o27LPfFb000968@casselton.net> <4B951CE2.6040507@semihalf.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tinguely@casselton.net, freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:23:18 -0000 cIn message: <4B951CE2.6040507@semihalf.com> Grzegorz Bernacki writes: : 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. Agreed. Why would we turn off caching for shared pages? I can understand read/write pages in a system that has a virtually index cache with the classic cache aliasing problems as a workaround for lousy hardware, but otherwise, this one has me scratching my head... And if there's only one copy of 'test' running, why does it hit the 'shared' case for this code? Warner From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 18:19:26 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 AA4031065687 for ; Mon, 8 Mar 2010 18:19:26 +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 5AF188FC18 for ; Mon, 8 Mar 2010 18:19:26 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id o28IJNq6045141; Mon, 8 Mar 2010 12:19:23 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1268072364; bh=SwLkuR6QIbxgMESo8h7kO7JgDly/LlkrZehvxUluEOw=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=hsyyL/cImf0mM/ae4FmkANPCSsEjYvH9s2OHld8RiHoeTKYWKJ8VpLbdQ6pHuX4rs KLPFVQDd3WODVCaa4/y7kStigCu/jVmRxP78PPiC6+60PW+OKxmGJATwhMbdVSaffa tpgUbb4UBurNokrhpg6lzv9mwzU2Nx1xkGIbrZvM= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id o28IJNe6045140; Mon, 8 Mar 2010 12:19:23 -0600 (CST) (envelope-from tinguely) Date: Mon, 8 Mar 2010 12:19:23 -0600 (CST) From: Mark Tinguely Message-Id: <201003081819.o28IJNe6045140@casselton.net> To: gjb@semihalf.com, imp@bsdimp.com In-Reply-To: <20100308.091516.295937982770284454.imp@bsdimp.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Mon, 08 Mar 2010 12:19:24 -0600 (CST) Cc: freebsd-arm@freebsd.org, tinguely@casselton.net Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 18:19:26 -0000 > In message: <4B951CE2.6040507@semihalf.com> > Grzegorz Bernacki writes: > : 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. > > Agreed. Why would we turn off caching for shared pages? I can > understand read/write pages in a system that has a virtually index > cache with the classic cache aliasing problems as a workaround for > lousy hardware, but otherwise, this one has me scratching my head... > > And if there's only one copy of 'test' running, why does it hit the > 'shared' case for this code? > > Warner Could you do this instead: + int stop; TAILQ_FOREACH(pv, &pg->md.pv_list, pv_list) { + if (pv->pv_flags & PVF_EXEC) + stop = 1; /* generate a count of the pv_entry uses */ if (pv->pv_flags & PVF_WRITE) { if (pv->pv_pmap == pmap_kernel()) kwritable++; else if (pv->pv_pmap == pm) uwritable++; writable++; } if (pv->pv_pmap == pmap_kernel()) kentries++; else { if (pv->pv_pmap == pm) uentries++; entries++; } } + if (stop) { + if (writable && entries) + printf("fix results %d %d %d %d\n", kwritable,uwritable, + kentries, uentries); + return; + } This would give counts to make sure there is not a logic error in fix_cache. My best guess kwritable/kentry will be non-zero and says there is another "dangling kernel allocation" somewhere. We allocate a page into a kernel mapping and then either: 1) we are not clearing the md.pv_kva entry all the time when allocation is freed. I thought I was careful. 2) someone is temporarilly allocating the page and not telling pmap that they are done with it. The information that this page is mapped to a kernel mapping is incorrectly remembered, and the cache are turned off. We could look in the free page code for a non-empty md.pv_kva entry to test this theory. md.pv_kva is set for kernel mappings, so the culiprit will be in the pmap_kenter calls. Thank-you. --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 18:42:02 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 5EE34106564A for ; Mon, 8 Mar 2010 18:42:02 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id E0D398FC1D for ; Mon, 8 Mar 2010 18:42:01 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o28Ifp0b031685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2010 19:41:52 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o28IfmQd029898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 19:41:48 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o28Ifm5v018872; Mon, 8 Mar 2010 19:41:48 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o28IfloW018871; Mon, 8 Mar 2010 19:41:47 +0100 (CET) (envelope-from ticso) Date: Mon, 8 Mar 2010 19:41:47 +0100 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20100308184147.GB11192@cicely7.cicely.de> References: <201003072125.o27LPfFb000968@casselton.net> <4B951CE2.6040507@semihalf.com> <20100308.091516.295937982770284454.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100308.091516.295937982770284454.imp@bsdimp.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: tinguely@casselton.net, freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 18:42:02 -0000 On Mon, Mar 08, 2010 at 09:15:16AM -0700, M. Warner Losh wrote: > cIn message: <4B951CE2.6040507@semihalf.com> > Grzegorz Bernacki writes: > : 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. > > Agreed. Why would we turn off caching for shared pages? I can > understand read/write pages in a system that has a virtually index > cache with the classic cache aliasing problems as a workaround for > lousy hardware, but otherwise, this one has me scratching my head... This puzzled me as well. What is the requirement for such a handling with shared pages? I though handing over shared data is done by cache-flush, barriers or whatever an architectur has for this. Most systems we talk about are single CPU, so it is just DMA and handing over dcache writes to icache, but we don't support self modifying code, so it is always done in a controlled way. And even for SMP systems handing over data requires using cache coherence mechanisms - e.g. those embedded in mutexes. So what is wrong in my picture and requires us to do special handling for shared pages on ARM? > And if there's only one copy of 'test' running, why does it hit the > 'shared' case for this code? > > Warner -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 19:37: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 766D31065670 for ; Mon, 8 Mar 2010 19:37:27 +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 2E7138FC18 for ; Mon, 8 Mar 2010 19:37:26 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id o28JbN7c049004; Mon, 8 Mar 2010 13:37:23 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1268077043; bh=o1EoRAfXvh3zaqeqAa+u3ZsQMU0r81aqJeFRVB0bqbw=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=YMwxAqFbwYOo8QpZhXiofjvxQUqQai4Xd5QdfaRgZ4d/rHrbzl1YxVbCRYWmv2UnO MbZthWrbVx9r5bwnWsn/+3JoQorjQA2xBMftgfV9r7xR+vONeBnRXqwc26kgaVcaBu umm1cFjxXCvRNSvMTiqwvcHUG4pwuWscaAriHqNE= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id o28JbNcU049003; Mon, 8 Mar 2010 13:37:23 -0600 (CST) (envelope-from tinguely) Date: Mon, 8 Mar 2010 13:37:23 -0600 (CST) From: Mark Tinguely Message-Id: <201003081937.o28JbNcU049003@casselton.net> To: ticso@cicely.de In-Reply-To: <20100308184147.GB11192@cicely7.cicely.de> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Mon, 08 Mar 2010 13:37:23 -0600 (CST) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 19:37:27 -0000 > > This puzzled me as well. > What is the requirement for such a handling with shared pages? > I though handing over shared data is done by cache-flush, barriers or > whatever an architectur has for this. > Most systems we talk about are single CPU, so it is just DMA and > handing over dcache writes to icache, but we don't support self > modifying code, so it is always done in a controlled way. > And even for SMP systems handing over data requires using > cache coherence mechanisms - e.g. those embedded in mutexes. > So what is wrong in my picture and requires us to do special handling > for shared pages on ARM? > > > And if there's only one copy of 'test' running, why does it hit the > > 'shared' case for this code? > > > > Warner > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ARMv4/ARMv5 use virtual indexed / virtual tagged level one caches. They may or may not have level two caches. This is the ARM chips that we currently support, and I will explain the rules below. Newest processors the ARMv6 can be virtual index / physical tagged or physical index / physical tagged level one caches; The ARM7 must have physical index / physical tag level one caches. The ARMv6 and ARMv7 have more pde/pte bit explaining the cache status on the "inner" and "outter" caches. The ARMv7 has the more mature cache management; it defines the "level of unity" and "level of coherence" for the caches. There is also a level snooping for the ARMv7 mulit-core, that I will just dance around. PIPT cache must be synced to the "level of coherency" before DMA and when modified from another process - think debugger in another address space modifying instruction code. ARMv6/ARMv7 have special address spaces to avoid tlb flushes. If they are not used, then tlbs have to be flushed on context switch. This is close to the i386/amd64 with the exception of DMA, the i386/amd64 have self snooping cache buses. VIVT cache rules: 1) flush cache and tlb on context change. 2) USER cache must be disabled if a physical page has AT LEAST one writable user mapping AND is also mapped more than one time in the same user address space. (multiple read mappings and no writes are fine, they take up multiple cache entries. Obviously, a single read or a single write is fine. If the mappings are in different user address spaces, we will be okay because the flush on context change will sync things up). 3) KERNEL spaces are global. a) If the page is mapped writable AT LEAST ONCE to a kernel space AND the page is mapped more than once, no matter if the second mapping is in the user or kernel space, all mappings must not be cached. b) If the page has only readable kernel mappings but at least one writable user mapping, the cache must be disabled for the mappings of page in this address space. This is slightly different from rule 2. Kernel mappings are typically writable, so this is a case that really does not happen. It gets a little tricky to implement, because we have to catch the transition from cache -> non-cache (change pte and wbinv/inv data or instruction caches) and from non-cache -> cache (change the pte). --Mark. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 19:55: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 ACDF0106566C for ; Mon, 8 Mar 2010 19:55:04 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 35C338FC17 for ; Mon, 8 Mar 2010 19:55:03 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o28Jssu3035249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2010 20:54:56 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o28JsoEJ032447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 20:54:50 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o28Jsob5019197; Mon, 8 Mar 2010 20:54:50 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o28Jsn62019196; Mon, 8 Mar 2010 20:54:49 +0100 (CET) (envelope-from ticso) Date: Mon, 8 Mar 2010 20:54:49 +0100 From: Bernd Walter To: Mark Tinguely Message-ID: <20100308195449.GE11192@cicely7.cicely.de> References: <20100308184147.GB11192@cicely7.cicely.de> <201003081937.o28JbNcU049003@casselton.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003081937.o28JbNcU049003@casselton.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@freebsd.org, ticso@cicely.de Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 19:55:04 -0000 On Mon, Mar 08, 2010 at 01:37:23PM -0600, Mark Tinguely wrote: > > > > > > This puzzled me as well. > > What is the requirement for such a handling with shared pages? > > I though handing over shared data is done by cache-flush, barriers or > > whatever an architectur has for this. > > Most systems we talk about are single CPU, so it is just DMA and > > handing over dcache writes to icache, but we don't support self > > modifying code, so it is always done in a controlled way. > > And even for SMP systems handing over data requires using > > cache coherence mechanisms - e.g. those embedded in mutexes. > > So what is wrong in my picture and requires us to do special handling > > for shared pages on ARM? > > > > > And if there's only one copy of 'test' running, why does it hit the > > > 'shared' case for this code? > > > > > > Warner > > > > -- > > B.Walter http://www.bwct.de > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > > ARMv4/ARMv5 use virtual indexed / virtual tagged level one caches. > They may or may not have level two caches. This is the ARM chips > that we currently support, and I will explain the rules below. > > Newest processors the ARMv6 can be virtual index / physical tagged or > physical index / physical tagged level one caches; The ARM7 must have > physical index / physical tag level one caches. The ARMv6 and ARMv7 > have more pde/pte bit explaining the cache status on the "inner" > and "outter" caches. The ARMv7 has the more mature cache management; > it defines the "level of unity" and "level of coherence" for the caches. > There is also a level snooping for the ARMv7 mulit-core, that I will > just dance around. PIPT cache must be synced to the "level of coherency" > before DMA and when modified from another process - think debugger in > another address space modifying instruction code. ARMv6/ARMv7 have > special address spaces to avoid tlb flushes. If they are not used, then > tlbs have to be flushed on context switch. This is close to the i386/amd64 > with the exception of DMA, the i386/amd64 have self snooping cache buses. > > VIVT cache rules: > > 1) flush cache and tlb on context change. > > 2) USER cache must be disabled if a physical page has AT LEAST one writable > user mapping AND is also mapped more than one time in the same user > address space. (multiple read mappings and no writes are fine, they take > up multiple cache entries. Obviously, a single read or a single write > is fine. If the mappings are in different user address spaces, we will > be okay because the flush on context change will sync things up). > > 3) KERNEL spaces are global. > a) If the page is mapped writable AT LEAST ONCE to a kernel space > AND the page is mapped more than once, no matter if the second > mapping is in the user or kernel space, all mappings must not > be cached. I never assumed to be happy without a direct map. > b) If the page has only readable kernel mappings but at least one > writable user mapping, the cache must be disabled for the mappings > of page in this address space. This is slightly different from > rule 2. Kernel mappings are typically writable, so this is a > case that really does not happen. > > It gets a little tricky to implement, because we have to catch the transition > from cache -> non-cache (change pte and wbinv/inv data or instruction caches) > and from non-cache -> cache (change the pte). Thanks for the detailed explanation. I took a while, but now I got it. My picture wasn't expecting caching virtual pages. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 20:23:43 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 8304F1065670 for ; Mon, 8 Mar 2010 20:23:43 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 0F72E8FC17 for ; Mon, 8 Mar 2010 20:23:42 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o28KNfkH046846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 8 Mar 2010 21:23:41 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o28KNcsA033629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 21:23:38 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o28KNchN019352; Mon, 8 Mar 2010 21:23:38 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o28KNcrj019351; Mon, 8 Mar 2010 21:23:38 +0100 (CET) (envelope-from ticso) Date: Mon, 8 Mar 2010 21:23:38 +0100 From: Bernd Walter To: arm@freebsd.org Message-ID: <20100308202337.GF11192@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Bernd Walter Subject: RM9200 tuning X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 20:23:43 -0000 The whole cache story is scary enough I think, but it showed that it is not avoidable to have uncacheable pages in some cases. There are a few facts about RM9200 systems, which most of you running those systems already know. Most systems have 16Mx32 SDRAM - although other configurations with x16 and different size are possible. Although there is an external SRAM bus I don't think there is any good sense to use it as general purpose RAM, since the ranges are small, 16bit and require lots of waitstates, which makes the slower than SDRAM in almost every case. There is also 16k fast internal SRAM, which isn't used within FreeBSD at all. Is there anything reasonable we can place in this RAM? Originally I thought once about ate RX buffers or kernel page tables. Atnother point are the clock speeds. There are 3 important clocks - USB clock is generated by a separate PLL and required to have a specific rate. CPU clock is generated by another PLL and is typically 180MHz, but allowed to be up to 205MHz IIRC. Peripheral clock is divided from CPU clock and is typically 60MHz, because 180MHz/3, but is allowed to be up to 80MHz. The limiting factor is the PLL, which can't produce more than 180MHz. But there are allowed settings, which might be faster in real world. One example is running the CPU with 160MHz, which allows the peripheral clock to be 80MHz. The CPU ist slower, but memory is much faster. The first not allowed thing is overclocking the PLL. I've seen the PLL to happily produce 288MHz and I think the restriction is just for the full temperature range and full xtal type range. In fact I've even seen the CPU to run with 288MHz, but that's another story. It should be OK to run the system with full ~205MHz in most cases, which also increases the peripheral clock including the SDRAM speed. SDRAM is typically rated with 133MHz or 100MHz, so no problem from this side. Then of course there is the possibility for overclocking the CPU as well as in the 288MHz case. Originally FreeBSD had assumed fixed clock rates. Knowing the peripheral rate is important for e.g. UART bps dividers. I think in the meantime it is possible to reconfigure the kernel to different clock rates - if yes what are the kernel options for it? Which would be the best place to reconfigure the PLL? I know how to do it and that it is done by the loader right now, but I would like to have it as a kernel tuneable. All I need to know is a good place in the kernel startup. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 20:58: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 470351065672 for ; Mon, 8 Mar 2010 20:58:33 +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 08A1F8FC1E for ; Mon, 8 Mar 2010 20:58:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o28Knu7w085668; Mon, 8 Mar 2010 13:49:56 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 08 Mar 2010 13:49:57 -0700 (MST) Message-Id: <20100308.134957.431102609571835335.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely7.cicely.de From: "M. Warner Losh" In-Reply-To: <20100308202337.GF11192@cicely7.cicely.de> References: <20100308202337.GF11192@cicely7.cicely.de> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org Subject: Re: RM9200 tuning 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, 08 Mar 2010 20:58:33 -0000 In message: <20100308202337.GF11192@cicely7.cicely.de> Bernd Walter writes: : Originally FreeBSD had assumed fixed clock rates. Only for the first few revs. Now it is settable with the AT91_MASTER_CLOCK option. : Knowing the peripheral rate is important for e.g. UART bps dividers. : I think in the meantime it is possible to reconfigure the kernel to : different clock rates - if yes what are the kernel options for it? : Which would be the best place to reconfigure the PLL? : I know how to do it and that it is done by the loader right now, but : I would like to have it as a kernel tuneable. : All I need to know is a good place in the kernel startup. Hmmm, I thought the kernel tried to read the master clock rate, but I can't find the code that does it anymore. The AT91 family have a register than can be read to get this value, so long as your board design conforms to the atmel documented restrictions on the clock xtal used. Or, as is usually the case with clocks on these parts, am I confusing this with something else :) Warner From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 21:04:41 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 5BCC11065670 for ; Mon, 8 Mar 2010 21:04:41 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [78.110.53.255]) by mx1.freebsd.org (Postfix) with ESMTP id 190548FC1D for ; Mon, 8 Mar 2010 21:04:39 +0000 (UTC) Received: from orion.SpringDaemons.com (unknown [99.48.191.9]) by mx0.deglitch.com (Postfix) with ESMTPA id 22B148FC4E; Mon, 8 Mar 2010 23:45:42 +0300 (MSK) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id A5B2839C4E; Mon, 8 Mar 2010 12:46:38 -0800 (PST) Date: Mon, 8 Mar 2010 12:46:38 -0800 From: Stanislav Sedov To: ticso@cicely.de Message-Id: <20100308124638.7de69681.stas@FreeBSD.org> In-Reply-To: <20100308202337.GF11192@cicely7.cicely.de> References: <20100308202337.GF11192@cicely7.cicely.de> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, Bernd Walter Subject: Re: RM9200 tuning 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, 08 Mar 2010 21:04:41 -0000 On Mon, 8 Mar 2010 21:23:38 +0100 Bernd Walter mentioned: > Originally FreeBSD had assumed fixed clock rates. > Knowing the peripheral rate is important for e.g. UART bps dividers. > I think in the meantime it is possible to reconfigure the kernel to > different clock rates - if yes what are the kernel options for it? > Which would be the best place to reconfigure the PLL? > I know how to do it and that it is done by the loader right now, but > I would like to have it as a kernel tuneable. > All I need to know is a good place in the kernel startup. > I think the best place to do this would be the loader itself. AFAIK, FreeBSD on AT91 doesn't assume any specific clock rate except the FSB clock rate and does the calibration of the CPU clock and xtal clock on startup. One of solutions is to add a loader tunable that will allow you to pass the FSB clock rate from the loader, instead of assuming the constant value. -- Stanislav Sedov ST4096-RIPE From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 21:24:13 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 D46F61065672 for ; Mon, 8 Mar 2010 21:24:13 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 5FE0D8FC27 for ; Mon, 8 Mar 2010 21:24:12 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o28LO51i061948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2010 22:24:05 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o28LO2Yh035643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 22:24:02 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o28LO2pW019600; Mon, 8 Mar 2010 22:24:02 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o28LO2c4019599; Mon, 8 Mar 2010 22:24:02 +0100 (CET) (envelope-from ticso) Date: Mon, 8 Mar 2010 22:24:01 +0100 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20100308212401.GG11192@cicely7.cicely.de> References: <20100308202337.GF11192@cicely7.cicely.de> <20100308.134957.431102609571835335.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100308.134957.431102609571835335.imp@bsdimp.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: arm@freebsd.org, ticso@cicely7.cicely.de, ticso@cicely.de Subject: Re: RM9200 tuning X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 21:24:14 -0000 On Mon, Mar 08, 2010 at 01:49:57PM -0700, M. Warner Losh wrote: > In message: <20100308202337.GF11192@cicely7.cicely.de> > Bernd Walter writes: > : Originally FreeBSD had assumed fixed clock rates. > > Only for the first few revs. Now it is settable with the > AT91_MASTER_CLOCK option. This is what I called the peripheral clock? So in the normal case I setup this value to 60,000,000? > : Knowing the peripheral rate is important for e.g. UART bps dividers. > : I think in the meantime it is possible to reconfigure the kernel to > : different clock rates - if yes what are the kernel options for it? > : Which would be the best place to reconfigure the PLL? > : I know how to do it and that it is done by the loader right now, but > : I would like to have it as a kernel tuneable. > : All I need to know is a good place in the kernel startup. > > Hmmm, I thought the kernel tried to read the master clock rate, but I > can't find the code that does it anymore. The AT91 family have a > register than can be read to get this value, so long as your board > design conforms to the atmel documented restrictions on the clock xtal > used. Ah - I hardly remember that there was something like this. I think it is initialized from the ROM code by comparing with the 32768 oscillator - without this it wouldn't be possible for the ROM code to xmodem the first boot code via DBGU. But I think it is just to get the xtal clock. At least it would be possible to calculate the remaining clocks from that. Well - I want something different. I want to reprogramm the PLL inside the kernel so I would be more interested to know where there would be a good place to inject code for this. It needs to be early enough before anything depending on the clock has startet. I don't care if trampoline code unzip the kernel at highest speed. > Or, as is usually the case with clocks on these parts, am I confusing > this with something else :) It sounds familar, but I do know that I had to hardcode the xtal speed in the bootcode - which isn't the worst thing, since the xtal is always 16MHz with my boards. Maybe is is used to setup the USB PLL later in the kernel. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 21:33:02 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 9CDC61065672; Mon, 8 Mar 2010 21:33:02 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 0B56C8FC0C; Mon, 8 Mar 2010 21:33:01 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o28LX0wa062407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2010 22:33:01 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o28LWvbD036089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 22:32:57 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o28LWv5a019641; Mon, 8 Mar 2010 22:32:57 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o28LWvLt019640; Mon, 8 Mar 2010 22:32:57 +0100 (CET) (envelope-from ticso) Date: Mon, 8 Mar 2010 22:32:57 +0100 From: Bernd Walter To: Stanislav Sedov Message-ID: <20100308213257.GI11192@cicely7.cicely.de> References: <20100308202337.GF11192@cicely7.cicely.de> <20100308124638.7de69681.stas@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100308124638.7de69681.stas@FreeBSD.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: arm@FreeBSD.org, Bernd Walter , ticso@cicely.de Subject: Re: RM9200 tuning X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 21:33:02 -0000 On Mon, Mar 08, 2010 at 12:46:38PM -0800, Stanislav Sedov wrote: > On Mon, 8 Mar 2010 21:23:38 +0100 > Bernd Walter mentioned: > > > Originally FreeBSD had assumed fixed clock rates. > > Knowing the peripheral rate is important for e.g. UART bps dividers. > > I think in the meantime it is possible to reconfigure the kernel to > > different clock rates - if yes what are the kernel options for it? > > Which would be the best place to reconfigure the PLL? > > I know how to do it and that it is done by the loader right now, but > > I would like to have it as a kernel tuneable. > > All I need to know is a good place in the kernel startup. > > > > I think the best place to do this would be the loader itself. AFAIK, FreeBSD > on AT91 doesn't assume any specific clock rate except the FSB clock rate and does > the calibration of the CPU clock and xtal clock on startup. One of solutions is to > add a loader tunable that will allow you to pass the FSB clock rate from the loader, > instead of assuming the constant value. Well I still don't use a real loader, just the plain bootcode. I would be very happy to switch to loader(8) with FICL, tuneables and bootpromt. Is it possible to do today? I was with Warner using my elfbuild hardware for the first time when he did the first steps on RM9200. Therefor I'm probably still using obsolete old quick and dirty hacks. If loader(8) can be used now it is the first thing I will change before trying anything else. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 22:18:58 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 0C6CD1065670 for ; Mon, 8 Mar 2010 22:18:58 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id A3F6A8FC0A for ; Mon, 8 Mar 2010 22:18:57 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o28MIseo065040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2010 23:18:54 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o28MIpI5037706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 23:18:51 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o28MIpoi019849; Mon, 8 Mar 2010 23:18:51 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o28MIoL1019848; Mon, 8 Mar 2010 23:18:50 +0100 (CET) (envelope-from ticso) Date: Mon, 8 Mar 2010 23:18:50 +0100 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20100308221850.GA19800@cicely7.cicely.de> References: <20100308202337.GF11192@cicely7.cicely.de> <20100308.134957.431102609571835335.imp@bsdimp.com> <20100308212401.GG11192@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100308212401.GG11192@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: arm@freebsd.org, ticso@cicely7.cicely.de, ticso@cicely.de Subject: Re: RM9200 tuning X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 22:18:58 -0000 On Mon, Mar 08, 2010 at 10:24:01PM +0100, Bernd Walter wrote: > On Mon, Mar 08, 2010 at 01:49:57PM -0700, M. Warner Losh wrote: > > In message: <20100308202337.GF11192@cicely7.cicely.de> > > Bernd Walter writes: > > : Originally FreeBSD had assumed fixed clock rates. > > > > Only for the first few revs. Now it is settable with the > > AT91_MASTER_CLOCK option. > > This is what I called the peripheral clock? > So in the normal case I setup this value to 60,000,000? > > > : Knowing the peripheral rate is important for e.g. UART bps dividers. > > : I think in the meantime it is possible to reconfigure the kernel to > > : different clock rates - if yes what are the kernel options for it? > > : Which would be the best place to reconfigure the PLL? > > : I know how to do it and that it is done by the loader right now, but > > : I would like to have it as a kernel tuneable. > > : All I need to know is a good place in the kernel startup. > > > > Hmmm, I thought the kernel tried to read the master clock rate, but I > > can't find the code that does it anymore. The AT91 family have a > > register than can be read to get this value, so long as your board > > design conforms to the atmel documented restrictions on the clock xtal > > used. > > Ah - I hardly remember that there was something like this. > I think it is initialized from the ROM code by comparing with the > 32768 oscillator - without this it wouldn't be possible for the ROM code > to xmodem the first boot code via DBGU. > But I think it is just to get the xtal clock. > At least it would be possible to calculate the remaining clocks from > that. > Well - I want something different. > I want to reprogramm the PLL inside the kernel so I would be more > interested to know where there would be a good place to inject code for > this. > It needs to be early enough before anything depending on the clock has > startet. > I don't care if trampoline code unzip the kernel at highest speed. > > > Or, as is usually the case with clocks on these parts, am I confusing > > this with something else :) > > It sounds familar, but I do know that I had to hardcode the xtal speed > in the bootcode - which isn't the worst thing, since the xtal is always > 16MHz with my boards. > Maybe is is used to setup the USB PLL later in the kernel. Yes - there is CKGR_MCFR to read out the xtal frequency. However this is not an exact value since it is counted with the 32768 oscillator. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 22:38:26 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 98B6C106566B for ; Mon, 8 Mar 2010 22:38:26 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [78.110.53.255]) by mx1.freebsd.org (Postfix) with ESMTP id 548A98FC12 for ; Mon, 8 Mar 2010 22:38:26 +0000 (UTC) Received: from orion.SpringDaemons.com (adsl-99-48-191-9.dsl.snfc21.sbcglobal.net [99.48.191.9]) by mx0.deglitch.com (Postfix) with ESMTPA id 2DC078FC4E; Tue, 9 Mar 2010 01:37:54 +0300 (MSK) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 0F9DE39C4E; Mon, 8 Mar 2010 14:38:51 -0800 (PST) Date: Mon, 8 Mar 2010 14:38:50 -0800 From: Stanislav Sedov To: ticso@cicely.de Message-Id: <20100308143850.ea62eec5.stas@FreeBSD.org> In-Reply-To: <20100308213257.GI11192@cicely7.cicely.de> References: <20100308202337.GF11192@cicely7.cicely.de> <20100308124638.7de69681.stas@FreeBSD.org> <20100308213257.GI11192@cicely7.cicely.de> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@FreeBSD.org, Bernd Walter Subject: Re: RM9200 tuning 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, 08 Mar 2010 22:38:26 -0000 On Mon, 8 Mar 2010 22:32:57 +0100 Bernd Walter mentioned: > Well I still don't use a real loader, just the plain bootcode. > I would be very happy to switch to loader(8) with FICL, tuneables and > bootpromt. > Is it possible to do today? > I was with Warner using my elfbuild hardware for the first time when he > did the first steps on RM9200. > Therefor I'm probably still using obsolete old quick and dirty hacks. > If loader(8) can be used now it is the first thing I will change before > trying anything else. I belive it should be pretty easy to port ubldr(8) to support AT91 as raj@ made it working on the Marverll ARM platform. I'm not sure which details should be reimplemented, though, but from what I seen it should be quite a little work required. I'm just using plain uboot loading direclty from flash without Atmel 1st level loader and then use uboot to load FreeBSD kernel/pass hints and kenv variables. I think I posted the relevant code a couple of times to the list, but maybe it really makes more sense to port loader(8) instead as my code isn't going to make it into the official uboot distribution. -- Stanislav Sedov ST4096-RIPE From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 22:54:26 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 9A50B106566C; Mon, 8 Mar 2010 22:54:26 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 067DD8FC12; Mon, 8 Mar 2010 22:54:25 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o28MsNgX066784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2010 23:54:24 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o28MsLeS038815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 23:54:21 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o28MsLPh019979; Mon, 8 Mar 2010 23:54:21 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o28MsLRs019978; Mon, 8 Mar 2010 23:54:21 +0100 (CET) (envelope-from ticso) Date: Mon, 8 Mar 2010 23:54:21 +0100 From: Bernd Walter To: Stanislav Sedov Message-ID: <20100308225420.GB19800@cicely7.cicely.de> References: <20100308202337.GF11192@cicely7.cicely.de> <20100308124638.7de69681.stas@FreeBSD.org> <20100308213257.GI11192@cicely7.cicely.de> <20100308143850.ea62eec5.stas@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100308143850.ea62eec5.stas@FreeBSD.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: arm@FreeBSD.org, Bernd Walter , ticso@cicely.de Subject: Re: RM9200 tuning X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 22:54:26 -0000 On Mon, Mar 08, 2010 at 02:38:50PM -0800, Stanislav Sedov wrote: > On Mon, 8 Mar 2010 22:32:57 +0100 > Bernd Walter mentioned: > > > Well I still don't use a real loader, just the plain bootcode. > > I would be very happy to switch to loader(8) with FICL, tuneables and > > bootpromt. > > Is it possible to do today? > > I was with Warner using my elfbuild hardware for the first time when he > > did the first steps on RM9200. > > Therefor I'm probably still using obsolete old quick and dirty hacks. > > If loader(8) can be used now it is the first thing I will change before > > trying anything else. > > I belive it should be pretty easy to port ubldr(8) to support AT91 as raj@ made it > working on the Marverll ARM platform. I'm not sure which details should be > reimplemented, though, but from what I seen it should be quite a little work > required. > > I'm just using plain uboot loading direclty from flash without Atmel 1st level > loader and then use uboot to load FreeBSD kernel/pass hints and kenv variables. > I think I posted the relevant code a couple of times to the list, but maybe it > really makes more sense to port loader(8) instead as my code isn't going to make > it into the official uboot distribution. The ability to configure kenv variables is a big win. I'm using sys/boot/arm/at91/boot2 from spiflash instead of uboot, which directly starts the kernel. The kernel has ugly hardcoded things, such as rootdev and hints. There is already a good amount of support for loader(8) in libat91 so it shouldn't be too hard to do. I may give it a try after finishing some other projects. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 23:06:03 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 0457D1065672; Mon, 8 Mar 2010 23:06:03 +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 A49EA8FC16; Mon, 8 Mar 2010 23:06:02 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id B5DBEC42D1; Tue, 9 Mar 2010 00:08:29 +0100 (CET) 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 XB6JNmhLX+Fv; Tue, 9 Mar 2010 00:08:29 +0100 (CET) Received: from [192.168.133.14] (nat2-133.ghnet.pl [91.150.223.133]) by smtp.semihalf.com (Postfix) with ESMTPSA id 12326C41E7; Tue, 9 Mar 2010 00:08:29 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <20100308143850.ea62eec5.stas@FreeBSD.org> Date: Tue, 9 Mar 2010 00:06:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100308202337.GF11192@cicely7.cicely.de> <20100308124638.7de69681.stas@FreeBSD.org> <20100308213257.GI11192@cicely7.cicely.de> <20100308143850.ea62eec5.stas@FreeBSD.org> To: Stanislav Sedov X-Mailer: Apple Mail (2.1077) Cc: arm@FreeBSD.org, Bernd Walter , ticso@cicely.de Subject: Re: RM9200 tuning 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, 08 Mar 2010 23:06:03 -0000 On 2010-03-08, at 23:38, Stanislav Sedov wrote: > On Mon, 8 Mar 2010 22:32:57 +0100 > Bernd Walter mentioned: >=20 >> Well I still don't use a real loader, just the plain bootcode. >> I would be very happy to switch to loader(8) with FICL, tuneables and >> bootpromt. >> Is it possible to do today? >> I was with Warner using my elfbuild hardware for the first time when = he >> did the first steps on RM9200. >> Therefor I'm probably still using obsolete old quick and dirty hacks. >> If loader(8) can be used now it is the first thing I will change = before >> trying anything else. >=20 > I belive it should be pretty easy to port ubldr(8) to support AT91 as = raj@ made it > working on the Marverll ARM platform. I'm not sure which details = should be > reimplemented, though, but from what I seen it should be quite a = little work > required. The loader(8) support for ARM is independent of any specific board, but = it's currently only integrated with U-Boot as an underlying firmware = (though it should not be difficult to integrate it with other = first-stage bootloaders provided they export some API for elementary = operations on devices). We have actually had it running so far on various Marvell systems (ARMv5 = and v6), TI DaVinci (v5) and EP93xx (also v5), as far as I remember. The = only requirement for running current loader(8) on ARM is that U-Boot is = built with CONFIG_API option. Rafal From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 23:17:05 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 8BA971065680; Mon, 8 Mar 2010 23:17:05 +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 0D2248FC1C; Mon, 8 Mar 2010 23:17:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o28N6LZX087336; Mon, 8 Mar 2010 16:06:21 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 08 Mar 2010 16:06:22 -0700 (MST) Message-Id: <20100308.160622.149607579725155764.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely7.cicely.de From: "M. Warner Losh" In-Reply-To: <20100308225420.GB19800@cicely7.cicely.de> References: <20100308213257.GI11192@cicely7.cicely.de> <20100308143850.ea62eec5.stas@FreeBSD.org> <20100308225420.GB19800@cicely7.cicely.de> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stas@FreeBSD.org, arm@FreeBSD.org Subject: Re: RM9200 tuning 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, 08 Mar 2010 23:17:05 -0000 In message: <20100308225420.GB19800@cicely7.cicely.de> Bernd Walter writes: : On Mon, Mar 08, 2010 at 02:38:50PM -0800, Stanislav Sedov wrote: : > On Mon, 8 Mar 2010 22:32:57 +0100 : > Bernd Walter mentioned: : > : > > Well I still don't use a real loader, just the plain bootcode. : > > I would be very happy to switch to loader(8) with FICL, tuneables and : > > bootpromt. : > > Is it possible to do today? : > > I was with Warner using my elfbuild hardware for the first time when he : > > did the first steps on RM9200. : > > Therefor I'm probably still using obsolete old quick and dirty hacks. : > > If loader(8) can be used now it is the first thing I will change before : > > trying anything else. : > : > I belive it should be pretty easy to port ubldr(8) to support AT91 as raj@ made it : > working on the Marverll ARM platform. I'm not sure which details should be : > reimplemented, though, but from what I seen it should be quite a little work : > required. : > : > I'm just using plain uboot loading direclty from flash without Atmel 1st level : > loader and then use uboot to load FreeBSD kernel/pass hints and kenv variables. : > I think I posted the relevant code a couple of times to the list, but maybe it : > really makes more sense to port loader(8) instead as my code isn't going to make : > it into the official uboot distribution. : : The ability to configure kenv variables is a big win. : I'm using sys/boot/arm/at91/boot2 from spiflash instead of uboot, which : directly starts the kernel. : The kernel has ugly hardcoded things, such as rootdev and hints. : There is already a good amount of support for loader(8) in libat91 : so it shouldn't be too hard to do. : I may give it a try after finishing some other projects. I have an 8MB SPI flash on one of my boards... Maybe I should get /boot/loader support going with it.. as well as the different GEOM_FOO partioning schemes... Certainly would make a certain local company interested... Warner From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 23:38: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 3817A106566C; Mon, 8 Mar 2010 23:38:33 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id BA2A38FC21; Mon, 8 Mar 2010 23:38:31 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o28NcSTR067711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Mar 2010 00:38:28 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o28NcMid043380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Mar 2010 00:38:22 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o28NcM9e020191; Tue, 9 Mar 2010 00:38:22 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o28NcMwp020190; Tue, 9 Mar 2010 00:38:22 +0100 (CET) (envelope-from ticso) Date: Tue, 9 Mar 2010 00:38:22 +0100 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20100308233822.GC19800@cicely7.cicely.de> References: <20100308213257.GI11192@cicely7.cicely.de> <20100308143850.ea62eec5.stas@FreeBSD.org> <20100308225420.GB19800@cicely7.cicely.de> <20100308.160622.149607579725155764.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100308.160622.149607579725155764.imp@bsdimp.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: stas@FreeBSD.org, arm@FreeBSD.org, ticso@cicely7.cicely.de, ticso@cicely.de Subject: Re: RM9200 tuning X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 23:38:33 -0000 On Mon, Mar 08, 2010 at 04:06:22PM -0700, M. Warner Losh wrote: > In message: <20100308225420.GB19800@cicely7.cicely.de> > Bernd Walter writes: > : On Mon, Mar 08, 2010 at 02:38:50PM -0800, Stanislav Sedov wrote: > : > On Mon, 8 Mar 2010 22:32:57 +0100 > : > Bernd Walter mentioned: > : > > : > > Well I still don't use a real loader, just the plain bootcode. > : > > I would be very happy to switch to loader(8) with FICL, tuneables and > : > > bootpromt. > : > > Is it possible to do today? > : > > I was with Warner using my elfbuild hardware for the first time when he > : > > did the first steps on RM9200. > : > > Therefor I'm probably still using obsolete old quick and dirty hacks. > : > > If loader(8) can be used now it is the first thing I will change before > : > > trying anything else. > : > > : > I belive it should be pretty easy to port ubldr(8) to support AT91 as raj@ made it > : > working on the Marverll ARM platform. I'm not sure which details should be > : > reimplemented, though, but from what I seen it should be quite a little work > : > required. > : > > : > I'm just using plain uboot loading direclty from flash without Atmel 1st level > : > loader and then use uboot to load FreeBSD kernel/pass hints and kenv variables. > : > I think I posted the relevant code a couple of times to the list, but maybe it > : > really makes more sense to port loader(8) instead as my code isn't going to make > : > it into the official uboot distribution. > : > : The ability to configure kenv variables is a big win. > : I'm using sys/boot/arm/at91/boot2 from spiflash instead of uboot, which > : directly starts the kernel. > : The kernel has ugly hardcoded things, such as rootdev and hints. > : There is already a good amount of support for loader(8) in libat91 > : so it shouldn't be too hard to do. > : I may give it a try after finishing some other projects. > > I have an 8MB SPI flash on one of my boards... Maybe I should get > /boot/loader support going with it.. as well as the different > GEOM_FOO partioning schemes... Certainly would make a certain local > company interested... I just thought about boot2 retrieving loader from SD instead of kernel. But you are probably right to retrieve the loader from flash instead. boot2 with UFS support is already too big for AT91 with just 8k SRAM. A boot2 with just flash support would be much smaller and loader then can switch between netboot and such, which currently has to be hardcoded to keep the size down. My boards usually have AT45DB161D (some early boards have 321C) chips. Considered the loader size on i386 this should fit. I remeber you also worked with boards booting from I2C flash? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 8 23:50:40 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 C5F2C106566B for ; Mon, 8 Mar 2010 23:50:40 +0000 (UTC) (envelope-from maksverver@geocities.com) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA238FC1A for ; Mon, 8 Mar 2010 23:50:39 +0000 (UTC) Received: from heaven.student.utwente.nl (heaven.student.utwente.nl [130.89.167.52]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o28NoYY7028245 for ; Tue, 9 Mar 2010 00:50:34 +0100 Message-ID: <4B958D45.7040608@geocities.com> Date: Tue, 09 Mar 2010 00:50:29 +0100 From: Maks Verver User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100308 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <201003081819.o28IJNe6045140@casselton.net> In-Reply-To: <201003081819.o28IJNe6045140@casselton.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: maksverver@geocities.com X-Spam-Status: No Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 23:50:40 -0000 On 03/08/2010 07:19 PM, Mark Tinguely wrote: > Could you do this instead: > > This would give counts to make sure there is not a logic error in fix_cache. I tried this (adding initialization of the flag variable) and the problem is triggered with (at least) these values: kwritable uwritable kentries uentries 1 0 1 0 1 0 1 1 0 1 0 1 1 0 1 2 The 1/0/1/1 case appears most frequently. Why executable pages are ever mapped writable in user-space, I don't know. It's useful for generated/self-modifying code obviously, but I would not expect any of the standard tools or libraries to rely on that. - Maks Verver. From owner-freebsd-arm@FreeBSD.ORG Tue Mar 9 00:02:01 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 4117F1065676; Tue, 9 Mar 2010 00:02:01 +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 E816F8FC12; Tue, 9 Mar 2010 00:02:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o28NwvSm088024; Mon, 8 Mar 2010 16:58:57 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 08 Mar 2010 16:58:57 -0700 (MST) Message-Id: <20100308.165857.535730620108851355.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely7.cicely.de From: "M. Warner Losh" In-Reply-To: <20100308233822.GC19800@cicely7.cicely.de> References: <20100308225420.GB19800@cicely7.cicely.de> <20100308.160622.149607579725155764.imp@bsdimp.com> <20100308233822.GC19800@cicely7.cicely.de> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stas@FreeBSD.org, arm@FreeBSD.org Subject: Re: RM9200 tuning 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, 09 Mar 2010 00:02:01 -0000 In message: <20100308233822.GC19800@cicely7.cicely.de> Bernd Walter writes: : On Mon, Mar 08, 2010 at 04:06:22PM -0700, M. Warner Losh wrote: : > In message: <20100308225420.GB19800@cicely7.cicely.de> : > Bernd Walter writes: : > : On Mon, Mar 08, 2010 at 02:38:50PM -0800, Stanislav Sedov wrote: : > : > On Mon, 8 Mar 2010 22:32:57 +0100 : > : > Bernd Walter mentioned: : > : > : > : > > Well I still don't use a real loader, just the plain bootcode. : > : > > I would be very happy to switch to loader(8) with FICL, tuneables and : > : > > bootpromt. : > : > > Is it possible to do today? : > : > > I was with Warner using my elfbuild hardware for the first time when he : > : > > did the first steps on RM9200. : > : > > Therefor I'm probably still using obsolete old quick and dirty hacks. : > : > > If loader(8) can be used now it is the first thing I will change before : > : > > trying anything else. : > : > : > : > I belive it should be pretty easy to port ubldr(8) to support AT91 as raj@ made it : > : > working on the Marverll ARM platform. I'm not sure which details should be : > : > reimplemented, though, but from what I seen it should be quite a little work : > : > required. : > : > : > : > I'm just using plain uboot loading direclty from flash without Atmel 1st level : > : > loader and then use uboot to load FreeBSD kernel/pass hints and kenv variables. : > : > I think I posted the relevant code a couple of times to the list, but maybe it : > : > really makes more sense to port loader(8) instead as my code isn't going to make : > : > it into the official uboot distribution. : > : : > : The ability to configure kenv variables is a big win. : > : I'm using sys/boot/arm/at91/boot2 from spiflash instead of uboot, which : > : directly starts the kernel. : > : The kernel has ugly hardcoded things, such as rootdev and hints. : > : There is already a good amount of support for loader(8) in libat91 : > : so it shouldn't be too hard to do. : > : I may give it a try after finishing some other projects. : > : > I have an 8MB SPI flash on one of my boards... Maybe I should get : > /boot/loader support going with it.. as well as the different : > GEOM_FOO partioning schemes... Certainly would make a certain local : > company interested... : : I just thought about boot2 retrieving loader from SD instead of : kernel. : But you are probably right to retrieve the loader from flash instead. : boot2 with UFS support is already too big for AT91 with just 8k SRAM. But the AT91RM9200 has 16k :) We are at about 9.5k, and further space savings is difficult. : A boot2 with just flash support would be much smaller and loader then : can switch between netboot and such, which currently has to be hardcoded : to keep the size down. : My boards usually have AT45DB161D (some early boards have 321C) chips. : Considered the loader size on i386 this should fit. : I remeber you also worked with boards booting from I2C flash? Yes. Warner From owner-freebsd-arm@FreeBSD.ORG Tue Mar 9 00:21:54 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 C36A51065675; Tue, 9 Mar 2010 00:21:54 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 4EDA78FC08; Tue, 9 Mar 2010 00:21:54 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o290LoDn068878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Mar 2010 01:21:50 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o290Llet044700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Mar 2010 01:21:47 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o290LlZf020383; Tue, 9 Mar 2010 01:21:47 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o290Ll3O020382; Tue, 9 Mar 2010 01:21:47 +0100 (CET) (envelope-from ticso) Date: Tue, 9 Mar 2010 01:21:47 +0100 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20100309002147.GD19800@cicely7.cicely.de> References: <20100308225420.GB19800@cicely7.cicely.de> <20100308.160622.149607579725155764.imp@bsdimp.com> <20100308233822.GC19800@cicely7.cicely.de> <20100308.165857.535730620108851355.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100308.165857.535730620108851355.imp@bsdimp.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.001, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: stas@FreeBSD.org, arm@FreeBSD.org, ticso@cicely7.cicely.de, ticso@cicely.de Subject: Re: RM9200 tuning X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 00:21:54 -0000 On Mon, Mar 08, 2010 at 04:58:57PM -0700, M. Warner Losh wrote: > In message: <20100308233822.GC19800@cicely7.cicely.de> > Bernd Walter writes: > : On Mon, Mar 08, 2010 at 04:06:22PM -0700, M. Warner Losh wrote: > : > In message: <20100308225420.GB19800@cicely7.cicely.de> > : > Bernd Walter writes: > : > : On Mon, Mar 08, 2010 at 02:38:50PM -0800, Stanislav Sedov wrote: > : > : > On Mon, 8 Mar 2010 22:32:57 +0100 > : > : > Bernd Walter mentioned: > : > : > > : > : > > Well I still don't use a real loader, just the plain bootcode. > : > : > > I would be very happy to switch to loader(8) with FICL, tuneables and > : > : > > bootpromt. > : > : > > Is it possible to do today? > : > : > > I was with Warner using my elfbuild hardware for the first time when he > : > : > > did the first steps on RM9200. > : > : > > Therefor I'm probably still using obsolete old quick and dirty hacks. > : > : > > If loader(8) can be used now it is the first thing I will change before > : > : > > trying anything else. > : > : > > : > : > I belive it should be pretty easy to port ubldr(8) to support AT91 as raj@ made it > : > : > working on the Marverll ARM platform. I'm not sure which details should be > : > : > reimplemented, though, but from what I seen it should be quite a little work > : > : > required. > : > : > > : > : > I'm just using plain uboot loading direclty from flash without Atmel 1st level > : > : > loader and then use uboot to load FreeBSD kernel/pass hints and kenv variables. > : > : > I think I posted the relevant code a couple of times to the list, but maybe it > : > : > really makes more sense to port loader(8) instead as my code isn't going to make > : > : > it into the official uboot distribution. > : > : > : > : The ability to configure kenv variables is a big win. > : > : I'm using sys/boot/arm/at91/boot2 from spiflash instead of uboot, which > : > : directly starts the kernel. > : > : The kernel has ugly hardcoded things, such as rootdev and hints. > : > : There is already a good amount of support for loader(8) in libat91 > : > : so it shouldn't be too hard to do. > : > : I may give it a try after finishing some other projects. > : > > : > I have an 8MB SPI flash on one of my boards... Maybe I should get > : > /boot/loader support going with it.. as well as the different > : > GEOM_FOO partioning schemes... Certainly would make a certain local > : > company interested... > : > : I just thought about boot2 retrieving loader from SD instead of > : kernel. > : But you are probably right to retrieve the loader from flash instead. > : boot2 with UFS support is already too big for AT91 with just 8k SRAM. > > But the AT91RM9200 has 16k :) We are at about 9.5k, and further space > savings is difficult. I would be lying if I say that I never looked at the AT91SAM9260. It is cheaper, faster, needs less external circuit and has less hardware drawbacks (especially worth mentioning are ATE and MCI) - but only 8k SRAM. My boot0spi is, including a simple RAM check, just 3585 bytes (codesize). It is mostly the UFS, netboot and SD support which makes boot2 that big. Just to init hardware and then copying loader(8) from SPI into SDRAM should easily fit into 8k. Or was there a different reason to mention that you have 8M flash? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Mar 9 10:04:26 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 4D5FF106566B for ; Tue, 9 Mar 2010 10:04:26 +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 BFCE98FC13 for ; Tue, 9 Mar 2010 10:04:25 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id A0474C42D1; Tue, 9 Mar 2010 11:06:53 +0100 (CET) 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 JICPC8MntJmv; Tue, 9 Mar 2010 11:06:53 +0100 (CET) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 20751C41E7; Tue, 9 Mar 2010 11:06:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <4B958D45.7040608@geocities.com> Date: Tue, 9 Mar 2010 11:04:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9A89179C-ACC6-41E6-A942-B62E206AA001@semihalf.com> References: <201003081819.o28IJNe6045140@casselton.net> <4B958D45.7040608@geocities.com> To: Maks Verver X-Mailer: Apple Mail (2.1077) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 10:04:26 -0000 On 2010-03-09, at 00:50, Maks Verver wrote: > The 1/0/1/1 case appears most frequently. Why executable pages are = ever > mapped writable in user-space, I don't know. It's useful for > generated/self-modifying code obviously, but I would not expect any of > the standard tools or libraries to rely on that. It's needed for example while debugging -- think about injecting = breakpoints etc. Rafal From owner-freebsd-arm@FreeBSD.ORG Tue Mar 9 16:12: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 A7EDB106564A for ; Tue, 9 Mar 2010 16:12:35 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 57DCB8FC14 for ; Tue, 9 Mar 2010 16:12:35 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 46FCCC42D1; Tue, 9 Mar 2010 17:15:03 +0100 (CET) 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 pTCP7AtiYjuz; Tue, 9 Mar 2010 17:15:02 +0100 (CET) Received: from [10.0.0.75] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPA id 98FF8C41E7; Tue, 9 Mar 2010 17:15:02 +0100 (CET) Message-ID: <4B967370.4000206@semihalf.com> Date: Tue, 09 Mar 2010 17:12:32 +0100 From: Grzegorz Bernacki User-Agent: Thunderbird 2.0.0.16 (X11/20090618) MIME-Version: 1.0 To: Maks Verver References: <201003081819.o28IJNe6045140@casselton.net> <4B958D45.7040608@geocities.com> In-Reply-To: <4B958D45.7040608@geocities.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 16:12:35 -0000 Maks Verver wrote: > On 03/08/2010 07:19 PM, Mark Tinguely wrote: >> Could you do this instead: >> >> This would give counts to make sure there is not a logic error in fix_cache. > > I tried this (adding initialization of the flag variable) and the > problem is triggered with (at least) these values: > > kwritable uwritable kentries uentries > 1 0 1 0 > 1 0 1 1 > 0 1 0 1 > 1 0 1 2 > It seems that probles is caused by shared mapping between kernel space and user space. We have page mapped as executable in user space and at the same time the same page is mapped in kernel space as writable (row 2 and 4 in table above). I am pretty sure that kernel mapping is from buffer space and the buffer was created to read .text segment from file to memory. I think that instead of turning off cache for user entries it is enough just to write-back and invalidate cache for kernel entry, assuming that code is already in buffer. In row 1 of table there is only one writable and executable kernel entry and I think it may be something allocated via kmem_alloc_wait() and it shouldn't not cause any trouble. In row 3 we have only one executable and writable user entry and it also shouldn't be a problem. I think that user stack is mapped as readable, writable and executable so maybe it was page from stack. grzesiek From owner-freebsd-arm@FreeBSD.ORG Tue Mar 9 18:11:44 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 1E8B8106566B for ; Tue, 9 Mar 2010 18:11:44 +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 D3F778FC13 for ; Tue, 9 Mar 2010 18:11:43 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id o29IBg3k006508; Tue, 9 Mar 2010 12:11:42 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1268158302; bh=YfZaAJjCxyKhv8pqW5vqLigaXX1oyYgZ/e5L8+kMyF0=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=jQI9s4yJX2qNsS4JAwZU/EMwv3fz03wTZnLZXFm/gcOynYV0EHzn067iNCmJIioSo u6Q/gAwUBtwKv+Q0Oq2n5/2v3Gs4AQaKwJYt59JwCT1BnWuxqJwU8D7oJnRB1Y2riK bcJ0TPmoTHAkkFpPhhLcha7Pe9wg1xZtpYSrA9iA= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id o29IBgDN006507; Tue, 9 Mar 2010 12:11:42 -0600 (CST) (envelope-from tinguely) Date: Tue, 9 Mar 2010 12:11:42 -0600 (CST) From: Mark Tinguely Message-Id: <201003091811.o29IBgDN006507@casselton.net> To: gjb@semihalf.com, maksverver@geocities.com In-Reply-To: <4B967370.4000206@semihalf.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Tue, 09 Mar 2010 12:11:42 -0600 (CST) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 18:11:44 -0000 Thank-you for running the pmap_fix_cache() counts on executable. They were what I expected, but it does not point to why. If anyone thinks we are still leaking kernel allocations, I would think the place for a conditional printf statement where the md.pv_kva is non-zero in vm_page_free_toq() where the hold_count is zero. --Mark Tinguely. From owner-freebsd-arm@FreeBSD.ORG Wed Mar 10 00:41:35 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 E4FC6106564A; Wed, 10 Mar 2010 00:41:35 +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 925188FC13; Wed, 10 Mar 2010 00:41:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2A0fY5t001829; Tue, 9 Mar 2010 19:41:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2A0fYSF001773; Wed, 10 Mar 2010 00:41:34 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 10 Mar 2010 00:41:34 GMT Message-Id: <201003100041.o2A0fYSF001773@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: Wed, 10 Mar 2010 00:41:36 -0000 TB --- 2010-03-10 00:40:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-10 00:40:01 - starting HEAD tinderbox run for arm/arm TB --- 2010-03-10 00:40:01 - cleaning the object tree TB --- 2010-03-10 00:40:16 - cvsupping the source tree TB --- 2010-03-10 00:40:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2010-03-10 00:40:34 - building world TB --- 2010-03-10 00:40:34 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-10 00:40:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-10 00:40:34 - TARGET=arm TB --- 2010-03-10 00:40:34 - TARGET_ARCH=arm TB --- 2010-03-10 00:40:34 - TZ=UTC TB --- 2010-03-10 00:40:34 - __MAKE_CONF=/dev/null TB --- 2010-03-10 00:40:34 - cd /src TB --- 2010-03-10 00:40:34 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 10 00:40:34 UTC 2010 >>> 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 [...] ===> secure/libexec/sftp-server (cleandir) rm -f sftp-server sftp-server.o sftp-common.o sftp-server-main.o roaming_dummy.o sftp-server.8.gz sftp-server.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> secure/libexec/ssh-keysign (cleandir) rm -f ssh-keysign ssh-keysign.o readconf.o roaming_dummy.o ssh-keysign.8.gz ssh-keysign.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> secure/libexec/ssh-pkcs11-helper (cleandir) cd: can't cd to /src/secure/libexec/ssh-pkcs11-helper *** Error code 2 Stop in /src/secure/libexec. *** Error code 1 Stop in /src/secure. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-10 00:41:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-10 00:41:34 - ERROR: failed to build world TB --- 2010-03-10 00:41:34 - 34.23 user 20.68 system 93.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 10 13:58:13 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 3BC011065672 for ; Wed, 10 Mar 2010 13:58:13 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8318FC1C for ; Wed, 10 Mar 2010 13:58:10 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id A5FF2C4273; Wed, 10 Mar 2010 15:00:32 +0100 (CET) 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 u2bTmCETqDTh; Wed, 10 Mar 2010 15:00:32 +0100 (CET) Received: from [10.0.0.75] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPA id 00422C41E7; Wed, 10 Mar 2010 15:00:31 +0100 (CET) Message-ID: <4B97A568.5080101@semihalf.com> Date: Wed, 10 Mar 2010 14:58:00 +0100 From: Grzegorz Bernacki User-Agent: Thunderbird 2.0.0.16 (X11/20090618) MIME-Version: 1.0 To: Mark Tinguely References: <201003072125.o27LPfFb000968@casselton.net> In-Reply-To: <201003072125.o27LPfFb000968@casselton.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 13:58:13 -0000 Mark Tinguely wrote: > FreeBSD-current has kernel and user witness turned on. Witness is for > locks, so it should not change the performance of a tight arithmetic loop > like this. > > I don't know the marvell interals, and from what I tell, their technial > docs require NDA. That said, many of the ARM processors also have a > instruction internal cache (instruction prefetch) in addition to the > instruction cache. I don't think the prefetch has an enable/disable. > > It looks like from the cpu identification that the the branch prediction > is turned on. Branch prediction compensates for the longer pipelines. > I can't see how in the tight loop how that could go astray. > > Thus says the ARM ARM: > > ARM implementations are free to choose how far ahead of the > current point of execution they prefetch instructions; either > a fixed or a dynamically varying number of instructions. As well > as being free to choose how many instructions to prefetch, an ARM > implementation can choose which possible future execution path to > prefetch along. For example, after a branch instruction, it can > choose to prefetch either the instruction following the branch > or the instruction at the branch target. This is known as branch > prediction. > > There are a few data dangling allocations that I would like to see > closed from the multiple kernel allocation fix. *IN THEORY, IF* a page > is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then > it is never marked as unallocated. *IN THEORY*, if that page is used > again, then we could falsely believe that page is being shared and > we turn off the cache, eventhough it is not shared. > > http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff > > * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in > the Sheeva implementation. This is a theoritical observation of a side > effect of the multiple kernel mapping patch that we did just before > FreeBSD 8-release. I instrumented code with KTRs and your theory is correct. Kernel reuse page which was previouly mapped via arm_nocache. Your patch should be applied to -current. grzesiek From owner-freebsd-arm@FreeBSD.ORG Wed Mar 10 14:05:24 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 5799B106566B for ; Wed, 10 Mar 2010 14:05:24 +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 D50958FC15 for ; Wed, 10 Mar 2010 14:05:20 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 37ED2C4273; Wed, 10 Mar 2010 15:07:47 +0100 (CET) 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 edmeael1PpQz; Wed, 10 Mar 2010 15:07:46 +0100 (CET) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 8CDA3C41E7; Wed, 10 Mar 2010 15:07:46 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <4B97A568.5080101@semihalf.com> Date: Wed, 10 Mar 2010 15:05:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0C313497-FA0C-4E93-A117-F73E4778C7FE@semihalf.com> References: <201003072125.o27LPfFb000968@casselton.net> <4B97A568.5080101@semihalf.com> To: Bernd Walter X-Mailer: Apple Mail (2.1077) Cc: Mark Tinguely , freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 14:05:24 -0000 On 2010-03-10, at 14:58, Grzegorz Bernacki wrote: >> There are a few data dangling allocations that I would like to see >> closed from the multiple kernel allocation fix. *IN THEORY, IF* a = page >> is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then >> it is never marked as unallocated. *IN THEORY*, if that page is used >> again, then we could falsely believe that page is being shared and >> we turn off the cache, eventhough it is not shared. >> http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff >> * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in >> the Sheeva implementation. This is a theoritical observation of a = side >> effect of the multiple kernel mapping patch that we did just before >> FreeBSD 8-release. >=20 > I instrumented code with KTRs and your theory is correct. Kernel reuse = page > which was previouly mapped via arm_nocache. Your patch should be = applied > to -current. Bernd, Could you confirm this also fixes the issues for you on the RM9200 = machine? If so, I'll go on and commit the changes. Rafal From owner-freebsd-arm@FreeBSD.ORG Wed Mar 10 14:21:32 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 49A65106566B for ; Wed, 10 Mar 2010 14:21:32 +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 E05C28FC31 for ; Wed, 10 Mar 2010 14:21:31 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id o2AELUW4048880; Wed, 10 Mar 2010 08:21:30 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1268230890; bh=GrMOS4TJPWLaIwyrEKPLNpkGQegqbwGOS3GeE30ndAc=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=U+VWBBmylIzA8tzNMATQWTCfA0H83PcAmy7gA/tcOTtdlFTTkLuNHNYJ6k7mzqKS7 qmMJVc8hPDGQK+jwGJ2HxXgDz94UWAlDOOeJUz6U9wbime+wQBgqmPm+YDk7BVgnk9 zw+mdfVEtblQm7XzGg4qS5pfWAkk4Nv3Y0rRjMs8= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id o2AELUng048879; Wed, 10 Mar 2010 08:21:30 -0600 (CST) (envelope-from tinguely) Date: Wed, 10 Mar 2010 08:21:30 -0600 (CST) From: Mark Tinguely Message-Id: <201003101421.o2AELUng048879@casselton.net> To: gjb@semihalf.com, tinguely@casselton.net In-Reply-To: <4B97A568.5080101@semihalf.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Wed, 10 Mar 2010 08:21:30 -0600 (CST) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 14:21:32 -0000 > > There are a few data dangling allocations that I would like to see > > closed from the multiple kernel allocation fix. *IN THEORY, IF* a page > > is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then > > it is never marked as unallocated. *IN THEORY*, if that page is used > > again, then we could falsely believe that page is being shared and > > we turn off the cache, eventhough it is not shared. > > > > http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff > > > > * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in > > the Sheeva implementation. This is a theoritical observation of a side > > effect of the multiple kernel mapping patch that we did just before > > FreeBSD 8-release. > > I instrumented code with KTRs and your theory is correct. Kernel reuse page > which was previouly mapped via arm_nocache. Your patch should be applied > to -current. > > grzesiek Thank-you. I would appreciate it if someone would commit that patch. It has been on my mind since FreeBSD 8.0-release. This patch should help some data buffers because we do not incorrectly think this page is still mapped to a KVA. I don't think this our I/O performance problem solution, Off-list, I have mentioned the belief that it may be beneficial to think of not turning off the cache DMA_COHERENT even for ARMv4/ARMv5. --Mark Tinguely. From owner-freebsd-arm@FreeBSD.ORG Wed Mar 10 14:28:19 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 60397106566B; Wed, 10 Mar 2010 14:28:19 +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 0D5198FC18; Wed, 10 Mar 2010 14:28:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2AESIiW020154; Wed, 10 Mar 2010 09:28:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2AESIHH020139; Wed, 10 Mar 2010 14:28:18 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 10 Mar 2010 14:28:18 GMT Message-Id: <201003101428.o2AESIHH020139@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: [releng_8 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: Wed, 10 Mar 2010 14:28:19 -0000 TB --- 2010-03-10 14:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-10 14:00:00 - starting RELENG_8 tinderbox run for arm/arm TB --- 2010-03-10 14:00:00 - cleaning the object tree TB --- 2010-03-10 14:00:08 - cvsupping the source tree TB --- 2010-03-10 14:00:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/arm/arm/supfile TB --- 2010-03-10 14:00:26 - building world TB --- 2010-03-10 14:00:26 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-10 14:00:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-10 14:00:26 - TARGET=arm TB --- 2010-03-10 14:00:26 - TARGET_ARCH=arm TB --- 2010-03-10 14:00:26 - TZ=UTC TB --- 2010-03-10 14:00:26 - __MAKE_CONF=/dev/null TB --- 2010-03-10 14:00:26 - cd /src TB --- 2010-03-10 14:00:26 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 10 14:00:26 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/lib/libc/sys/sched_setparam.2 > sched_setparam.2.gz gzip -cn /src/lib/libc/sys/sched_setscheduler.2 > sched_setscheduler.2.gz gzip -cn /src/lib/libc/sys/sched_yield.2 > sched_yield.2.gz gzip -cn /src/lib/libc/sys/sctp_generic_recvmsg.2 > sctp_generic_recvmsg.2.gz gzip -cn /src/lib/libc/sys/sctp_generic_sendmsg.2 > sctp_generic_sendmsg.2.gz gzip -cn /src/lib/libc/sys/sctp_peeloff.2 > sctp_peeloff.2.gz gzip -cn /src/lib/libc/sys/select.2 > select.2.gz /libexec/ld-elf.so.1: Cannot open "/lib/libncurses.so.8" *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-10 14:28:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-10 14:28:18 - ERROR: failed to build world TB --- 2010-03-10 14:28:18 - 1165.76 user 320.11 system 1697.95 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 10 14:38:22 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 DEF511065677 for ; Wed, 10 Mar 2010 14:38:22 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 48ADF8FC1C for ; Wed, 10 Mar 2010 14:38:21 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o2AEcFhs078070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Mar 2010 15:38:15 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o2AEcCLe045621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Mar 2010 15:38:12 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o2AEcCop031141; Wed, 10 Mar 2010 15:38:12 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o2AEcBwq031140; Wed, 10 Mar 2010 15:38:11 +0100 (CET) (envelope-from ticso) Date: Wed, 10 Mar 2010 15:38:11 +0100 From: Bernd Walter To: Rafal Jaworowski Message-ID: <20100310143811.GJ25023@cicely7.cicely.de> References: <201003072125.o27LPfFb000968@casselton.net> <4B97A568.5080101@semihalf.com> <0C313497-FA0C-4E93-A117-F73E4778C7FE@semihalf.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C313497-FA0C-4E93-A117-F73E4778C7FE@semihalf.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.013, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Mark Tinguely , Bernd Walter , freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 14:38:22 -0000 On Wed, Mar 10, 2010 at 03:05:14PM +0100, Rafal Jaworowski wrote: > > On 2010-03-10, at 14:58, Grzegorz Bernacki wrote: > > >> There are a few data dangling allocations that I would like to see > >> closed from the multiple kernel allocation fix. *IN THEORY, IF* a page > >> is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then > >> it is never marked as unallocated. *IN THEORY*, if that page is used > >> again, then we could falsely believe that page is being shared and > >> we turn off the cache, eventhough it is not shared. > >> http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff > >> * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in > >> the Sheeva implementation. This is a theoritical observation of a side > >> effect of the multiple kernel mapping patch that we did just before > >> FreeBSD 8-release. > > > > I instrumented code with KTRs and your theory is correct. Kernel reuse page > > which was previouly mapped via arm_nocache. Your patch should be applied > > to -current. > > Bernd, > Could you confirm this also fixes the issues for you on the RM9200 machine? If so, I'll go on and commit the changes. For me it helped to get back to the speed of my older systems. Someone mentioned that even with this patch the speed can still drop after some time. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Wed Mar 10 15:53:21 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 A575D1065670 for ; Wed, 10 Mar 2010 15:53:21 +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 C13998FC08 for ; Wed, 10 Mar 2010 15:53:20 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 34EC9C4273; Wed, 10 Mar 2010 16:55:48 +0100 (CET) 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 YFFQNkuWT4ao; Wed, 10 Mar 2010 16:55:47 +0100 (CET) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 96ACCC41E7; Wed, 10 Mar 2010 16:55:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <4B9509C5.7050804@geocities.com> Date: Wed, 10 Mar 2010 16:53:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201003072125.o27LPfFb000968@casselton.net> <4B9509C5.7050804@geocities.com> To: Maks Verver X-Mailer: Apple Mail (2.1077) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 15:53:21 -0000 On 2010-03-08, at 15:29, Maks Verver wrote: > Next up, this patch: >=20 >> http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff >=20 > No idea what this does, but it helps a lot: >=20 > %time ./test > 9.000u 0.000s 0:09.11 99.2% 40+1324k 0+0io 0pf+0w >=20 > That's much better than the 280+ seconds from before. But it's still > nearly twice as long as Linux takes. >=20 > There is more weirdness though. If I freshly boot the system I get > timings like these, and even nbench reports decent scores. However, if = I > do a couple things like rerun/recompile nbench, then at some point > something 'breaks' and the performance goes back down to what it used = to be. Mark, Can you confirm this worsening over time happens with a fresh (from = scratch) kernel build (with Mark T. patch applied)? Please provide the = scenario / steps which lead to this behaviour. Rafal From owner-freebsd-arm@FreeBSD.ORG Wed Mar 10 16:42:19 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 494C61065672 for ; Wed, 10 Mar 2010 16:42:19 +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 B97638FC16 for ; Wed, 10 Mar 2010 16:42:18 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id o2AGgFB2056915; Wed, 10 Mar 2010 10:42:15 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1268239336; bh=wHkQbXEpGNJUiYvZKD/5ZBkmDMAXPsdirvfq8HgMgZs=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=l5B0uAZsFHcDzGwCa3TXqsm+A7qgkIu60BbR9qLZEkO0TuHF+AAOt6FmQT18CXL02 QJ71AlqJYb9EoqCainI0l8lIlERsamEHNria+WsBvIqeJ/w21ukjrjCacG0iIr6qBN BJAnbhoPxK7eF46yf1TSPiZkqlG1NU7gwCYFSOkI= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id o2AGgF1B056912; Wed, 10 Mar 2010 10:42:15 -0600 (CST) (envelope-from tinguely) Date: Wed, 10 Mar 2010 10:42:15 -0600 (CST) From: Mark Tinguely Message-Id: <201003101642.o2AGgF1B056912@casselton.net> To: ticso@cicely.de In-Reply-To: <20100310143811.GJ25023@cicely7.cicely.de> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Wed, 10 Mar 2010 10:42:16 -0600 (CST) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 16:42:19 -0000 On Wed Mar 10 at 0:38:20am, Bernd Walter wrote: > > On Wed, Mar 10, 2010 at 03:05:14PM +0100, Rafal Jaworowski wrote: > > > > On 2010-03-10, at 14:58, Grzegorz Bernacki wrote: > > > > >> There are a few data dangling allocations that I would like to see > > >> closed from the multiple kernel allocation fix. *IN THEORY, IF* a page > > >> is allocated via the arm_nocache (DMA COHERENT) or a sendfile, then > > >> it is never marked as unallocated. *IN THEORY*, if that page is used > > >> again, then we could falsely believe that page is being shared and > > >> we turn off the cache, eventhough it is not shared. > > >> http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff > > >> * Disclaimer: I am not sure if DMA COHERENT nor sendfiles are used in > > >> the Sheeva implementation. This is a theoritical observation of a side > > >> effect of the multiple kernel mapping patch that we did just before > > >> FreeBSD 8-release. > > > > > > I instrumented code with KTRs and your theory is correct. Kernel reuse pa ge > > > which was previouly mapped via arm_nocache. Your patch should be applied > > > to -current. > > > > Bernd, > > Could you confirm this also fixes the issues for you on the RM9200 machine? If so, I'll go on and commit the changes. > > For me it helped to get back to the speed of my older systems. > Someone mentioned that even with this patch the speed can still drop > after some time. The orginial patch is needed, but the above would imply that there are more places that we are not removing the remberence of the kernel allocation. The assumption was the allocations are to the kernel map and are originating rom pmap_kenter/pmap_qenter and will be removed with pmap_kremove/pmap_qremove. I looked at the kernel sources yesterday; pmap_qenter/pmap_qremove is used exclusively in the machine independant code. Maybe the pmap_qremove is not used (process termination?, another allocation with remove?) and the page is freed instead with the pmap_remove_page, pmap_remove_all, pmap_remove routines. A test panic in vm_page_free_toq() on non-zero md.pv_kva will tell us which routine is releasing the page. I will think some more about the pmap_remove_page, pmap_remove_all, pmap_remove paths. --Mark Tinguely. From owner-freebsd-arm@FreeBSD.ORG Wed Mar 10 18:07:16 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 543D01065672 for ; Wed, 10 Mar 2010 18:07:16 +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 E519A8FC23 for ; Wed, 10 Mar 2010 18:07:15 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id o2AI7ESS061784; Wed, 10 Mar 2010 12:07:14 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1268244434; bh=j3uIN8dPjmc9JKRFzK/wx77WV20zryLBBJlRKG/t1cQ=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=rd/TiS7RNmtY8gxRl+ANjG9mysDu4Q4C8lbJadDSt25F0SrgIxqH+VAjPUsP1p3f5 GGj3cWw64jJZrDy0YekwpZPPclcQZzrmB8Y/s8fcgQKzjJGsCcJDOutg4szkL3Ep6C dPAd4qxh3ivBj473LjDxbZeziclc8bRSKT/7UPCA= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id o2AI7ES2061783; Wed, 10 Mar 2010 12:07:14 -0600 (CST) (envelope-from tinguely) Date: Wed, 10 Mar 2010 12:07:14 -0600 (CST) From: Mark Tinguely Message-Id: <201003101807.o2AI7ES2061783@casselton.net> To: maksverver@geocities.com, raj@semihalf.com In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Wed, 10 Mar 2010 12:07:14 -0600 (CST) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 18:07:16 -0000 On Wed, 10 Mar 2010 16:53pm, Rafal Jaworowski asks: > > On 2010-03-08, at 15:29, Maks Verver wrote: > > > Next up, this patch: > >=20 > >> http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff > >=20 > > No idea what this does, but it helps a lot: > >=20 > > %time ./test > > 9.000u 0.000s 0:09.11 99.2% 40+1324k 0+0io 0pf+0w > >=20 > > That's much better than the 280+ seconds from before. But it's still > > nearly twice as long as Linux takes. > >=20 > > There is more weirdness though. If I freshly boot the system I get > > timings like these, and even nbench reports decent scores. However, if = > I > > do a couple things like rerun/recompile nbench, then at some point > > something 'breaks' and the performance goes back down to what it used = > to be. > > Mark, > Can you confirm this worsening over time happens with a fresh (from = > scratch) kernel build (with Mark T. patch applied)? Please provide the = > scenario / steps which lead to this behaviour. > > Rafal I believe there is still a path that md.pv_kva is not being zeroed before the page is freed. Later, when the page is re-mapped either for data or executable, we think (because md.pv_kva is non-zero), that this page is still mapped into the KVA stored at md.pv_kva. My patch was for two places in the the machine dependant code that we were not freeing the md.pv_kva. We can prove this theory by placing a temporary printf statement or even better a panic in vm_page_free_toq(). Something like: if (m->hold_count != 0) { m->flags &= ~PG_ZERO; vm_page_enqueue(PQ_HOLD, m); } else { + KASSERT(!m->md.pv_kva, + ("vm_page_free_toq: pva nonzero %p", m->md.pv_kva)); /* * Restore the default memory attribute to the page. */ if (pmap_page_get_memattr(m) != VM_MEMATTR_DEFAULT) pmap_page_set_memattr(m, VM_MEMATTR_DEFAULT); Since the machine indepentant sources look pretty consistent on pmap_qenter/pmap_qremove calls, I bet one of the pmap_remove* routines will be freeing the page and in the panic traceback. pmap_remove* was not the path I was expecting the kernel mapped page to be removed. --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Thu Mar 11 21:18:37 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 E8BF31065676 for ; Thu, 11 Mar 2010 21:18:37 +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 9C9208FC13 for ; Thu, 11 Mar 2010 21:18:37 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id C1E5CC4273; Thu, 11 Mar 2010 22:21:09 +0100 (CET) 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 uU6cwRykQNTa; Thu, 11 Mar 2010 22:21:09 +0100 (CET) Received: from [192.168.133.14] (nat2-133.ghnet.pl [91.150.223.133]) by smtp.semihalf.com (Postfix) with ESMTPSA id 41A19C41E7; Thu, 11 Mar 2010 22:21:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <201003101421.o2AELUng048879@casselton.net> Date: Thu, 11 Mar 2010 22:18:34 +0100 Content-Transfer-Encoding: 7bit Message-Id: <6F6258B6-83F7-452C-A741-5D54738A7C8D@semihalf.com> References: <201003101421.o2AELUng048879@casselton.net> To: Mark Tinguely X-Mailer: Apple Mail (2.1077) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 21:18:38 -0000 On 2010-03-10, at 15:21, Mark Tinguely wrote: > Thank-you. I would appreciate it if someone would commit that patch. It > has been on my mind since FreeBSD 8.0-release. This patch should help some > data buffers because we do not incorrectly think this page is still mapped > to a KVA. Commited @ r205028. Many thanks! Rafal From owner-freebsd-arm@FreeBSD.ORG Fri Mar 12 18:06:26 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 DA3A1106564A for ; Fri, 12 Mar 2010 18:06:26 +0000 (UTC) (envelope-from maksverver@geocities.com) Received: from mx.utwente.nl (mx1.utsp.utwente.nl [130.89.2.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5CCF78FC1A for ; Fri, 12 Mar 2010 18:06:25 +0000 (UTC) Received: from heaven.student.utwente.nl (heaven.student.utwente.nl [130.89.167.52]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o2CHpfpo002275 for ; Fri, 12 Mar 2010 18:51:41 +0100 Message-ID: <4B9A7F2D.2080202@geocities.com> Date: Fri, 12 Mar 2010 18:51:41 +0100 From: Maks Verver User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100308 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <201003072125.o27LPfFb000968@casselton.net> <4B9509C5.7050804@geocities.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: maksverver@geocities.com X-Spam-Status: No Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 18:06:26 -0000 On 03/10/2010 04:53 PM, Rafal Jaworowski wrote: > Mark, Can you confirm this worsening over time happens with a fresh > (from scratch) kernel build (with Mark T. patch applied)? Please > provide the scenario / steps which lead to this behaviour. Was this directed at me? If so, I've rebuilt the distribution from CURRENT sources (previously, I used 8-STABLE with some patches applied) which I believe includes Mark Tinguely's patches. With these patches, the problem doesn't occur for tests that I run immediately after booting. However, if I create a new binary (either by recompiling, which is what I did before, or simply by copying, as I found out) then this new binary executes slowly: elysium# time ./test 9.000u 0.000s 0:09.07 99.6% 40+1324k 1+0io 0pf+0w elysium# cp test test2 elysium# time ./test2 287.000u 0.000s 4:48.54 99.5% 40+1322k 0+0io 0pf+0w 9 seconds is still slower than it should be (Linux runs this test program in 5.4 s) but this may well be a completely separate issue. I also added the KASSERT line that Mark Tinguely suggested, but I forgot to enable the INVARIANT option when rebuilding the kernel. I'll have to get back to you on that one. Kind regards, Maks Verver. From owner-freebsd-arm@FreeBSD.ORG Fri Mar 12 20:07:10 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 E872A106566B for ; Fri, 12 Mar 2010 20:07:10 +0000 (UTC) (envelope-from maksverver@geocities.com) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.freebsd.org (Postfix) with ESMTP id 6F69F8FC13 for ; Fri, 12 Mar 2010 20:07:09 +0000 (UTC) Received: from heaven.student.utwente.nl (heaven.student.utwente.nl [130.89.167.52]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o2CJwPBW032119; Fri, 12 Mar 2010 20:58:25 +0100 Message-ID: <4B9A9CE0.2090509@geocities.com> Date: Fri, 12 Mar 2010 20:58:24 +0100 From: Maks Verver User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100308 Thunderbird/3.0.3 MIME-Version: 1.0 To: Mark Tinguely References: <201003101807.o2AI7ES2061783@casselton.net> In-Reply-To: <201003101807.o2AI7ES2061783@casselton.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: maksverver@geocities.com X-Spam-Status: No Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 20:07:11 -0000 On 03/10/2010 07:07 PM, Mark Tinguely wrote: > I believe there is still a path that md.pv_kva is not being zeroed > before the page is freed. [..] We can prove this theory by placing a > temporary printf statement or even better a panic in > vm_page_free_toq(). I tried this, and it triggers immediately during boot, but I don't really know what to do at the debugger prompt except produce a backtrace. Here's the complete log: ## Starting application at 0x00900100 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #2: Fri Mar 12 18:49:03 CET 2010 root@heaven.student.utwente.nl:/usr/obj/arm/usr/src/sys/ELYSIUM arm CPU: Feroceon 88FR131 rev 1 (Marvell core) DC enabled IC enabled WB enabled EABT branch prediction enabled 16KB/32B 4-way Instruction cache 16KB/32B 4-way write-back-locking-C Data cache real memory = 536870912 (512 MB) avail memory = 520273920 (496 MB) SOC: Marvell 88F6281 rev A0, TClock 200MHz mbus0: on motherboard ic0: at mem 0xf1020200-0xf102023b on mbus0 timer0: at mem 0xf1020300-0xf102032f irq 1 on mbus0 timer0: [FILTER] rtc0: at mem 0xf1010300-0xf1010307 on mbus0 gpio0: at mem 0xf1010100-0xf101011f irq 35,36,37,38,39,40,41 on mbus0 gpio0: [FILTER] gpio0: [FILTER] gpio0: [FILTER] gpio0: [FILTER] gpio0: [FILTER] gpio0: [FILTER] gpio0: [FILTER] uart0: <16550 or compatible> at mem 0xf1012000-0xf101201f irq 33 on mbus0 uart0: [FILTER] uart0: console (115740,n,8,1) uart1: <16550 or compatible> at mem 0xf1012100-0xf101211f irq 34 on mbus0 uart1: [FILTER] ehci0: at mem 0xf1050000-0xf1050fff irq 48,19 on mbus0 ehci0: [FILTER] ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: set host controller mode usbus0: on ehci0 mge0: at mem 0xf1072000-0xf1073fff irq 12,13,14,11,46 on mbus0 mge0: Ethernet address: 00:50:43:01:d8:2c miibus0: on mge0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto mge0: [ITHREAD] mge0: [ITHREAD] Timecounter "CPU Timer" frequency 200000000 Hz quality 1000 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 Trying to mount root from ufs:/dev/da0s1d. Press CTRL+C to abort. ROOT MOUNT ERROR: If you have invalid mount options, reboot, and first try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove invalid mount options from /etc/fstab. ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered Trying to mount root from ufs:/dev/da0s1d. Press CTRL+C to abort. ugen0.2: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0000 Trying to mount root from ufs:/dev/da0s1d. Press CTRL+C to abort. umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 480MB (983808 512 byte sectors: 64H 32S/T 480C) Trying to mount root from ufs:/dev/da0s1d. Press CTRL+C to abort. WARNING: / was not properly dismounted panic: vm_page_free_toq: pva nonzero 0xc85cc000 KDB: enter: panic [ thread pid 1 tid 100001 ] Stopped at kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! db> trace Tracing pid 1 tid 100001 td 0xc341e000 kdb_enter() at kdb_enter+0x10 scp=0xc09d1844 rlv=0xc09a3110 (panic+0xcc) rsp=0xcf23e804 rfp=0xcf23e818 r4=0x00000100 panic() at panic+0x14 scp=0xc09a3058 rlv=0xc0b1555c (vm_page_free_toq+0x138) rsp=0xcf23e82c rfp=0xcf23e840 vm_page_free_toq() at vm_page_free_toq+0x10 scp=0xc0b15434 rlv=0xc0b156e8 (vm_page_free+0x1c) rsp=0xcf23e844 rfp=0xcf23e850 r4=0xc0dafbfc vm_page_free() at vm_page_free+0x10 scp=0xc0b156dc rlv=0xc0a105f4 (allocbuf+0xad8) rsp=0xcf23e854 rfp=0xcf23e870 allocbuf() at allocbuf+0xa30 scp=0xc0a1054c rlv=0xc0a10bac (brelse+0x48c) rsp=0xcf23e874 rfp=0xcf23e8c0 r7=0x00000000 r6=0x00001000 r5=0xc0b74b10 r4=0xc0bfd500 brelse() at brelse+0x10 scp=0xc0a10730 rlv=0xc0aebba0 (ffs_sbupdate+0x265c) rsp=0xcf23e8c4 rfp=0xcf23e9c0 r10=0x00000000 r9=0x00010000 r8=0x00000000 r7=0xc85cc000 r6=0xc85cc0d4 r5=0x00000000 r4=0xc0be7e08 ffs_sbupdate() at ffs_sbupdate+0xe28 scp=0xc0aea36c rlv=0xc0a215f4 (vfs_donmount+0xc84) rsp=0xcf23e9c4 rfp=0xcf23ec00 r10=0xc3602518 r9=0x00000003 r8=0xcf23ec04 r7=0xc3602518 r6=0x00004001 r5=0xcf23eb50 r4=0x00000000 vfs_donmount() at vfs_donmount+0x10 scp=0xc0a20980 rlv=0xc0a21cb4 (kernel_mount+0x80) rsp=0xcf23ec04 rfp=0xcf23ec3c r10=0xc3541940 r9=0x00000003 r8=0xc3628e80 r7=0xc3541930 r6=0x00000000 r5=0xc3541930 r4=0xffffffff kernel_mount() at kernel_mount+0x10 scp=0xc0a21c44 rlv=0xc0a21fb0 (kernel_vmount+0x294) rsp=0xcf23ec40 rfp=0xcf23edf0 r6=0x00000000 r5=0xc0b77118 r4=0xffffffff kernel_vmount() at kernel_vmount+0x84 scp=0xc0a21da0 rlv=0xc0a227c0 (vfs_mountroot+0x2a4) rsp=0xcf23edf4 rfp=0xcf23ee2c r10=0x00000000 r9=0xc341c000 r8=0xc0b770d8 r7=0x00000000 r6=0x00000003 r5=0xffffffff r4=0xc0bf7b2c vfs_mountroot() at vfs_mountroot+0x10 scp=0xc0a2252c rlv=0xc0964734 (exec_shell_imgact+0x7ac) rsp=0xcf23ee30 rfp=0xcf23ee84 r8=0xc341c000 r7=0xcf23eeac r6=0x00000000 r5=0xc0b6339c r4=0xc0bf1ab8 exec_shell_imgact() at exec_shell_imgact+0x768 scp=0xc09646f0 rlv=0xc097dc54 (fork_exit+0x8c) rsp=0xcf23ee88 rfp=0xcf23eea8 r10=0x00000000 r9=0x00000000 r8=0xc341c000 r7=0xcf23eeac r6=0x00000000 r5=0xc09646e0 r4=0xc341e000 fork_exit() at fork_exit+0x10 scp=0xc097dbd8 rlv=0xc0b34410 (fork_trampoline+0x14) rsp=0xcf23eeac rfp=0x00000000 r8=0x00000000 r7=0x00000000 r6=0x00000000 r5=0x00000000 r4=0xc09646e0 Does this help? - Maks Verver. From owner-freebsd-arm@FreeBSD.ORG Fri Mar 12 21:20:55 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 A8CFC1065675 for ; Fri, 12 Mar 2010 21:20:55 +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 64C868FC1A for ; Fri, 12 Mar 2010 21:20:54 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id o2CLKqTL090462; Fri, 12 Mar 2010 15:20:52 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1268428853; bh=34bk45194Y3Xzv76R0eJoFPLzLhR8YEx1o9oZPFVHcM=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=Nrdneop1JycVJXPg5RYgU3JRx7lfc3Fh+qSAZckxqZi+6mpcwc/WY1Og59bZOpzu4 +Bh4pyN3qThXLImcFiMGnBpXDWHk4okUytLAFe4qtWfe2KkeyB4ShHOWNHks23APXy 7YkwgqPLKquhE/TnGSYjtOT3O243CRdi8+rCTKvw= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id o2CLKqVQ090461; Fri, 12 Mar 2010 15:20:52 -0600 (CST) (envelope-from tinguely) Date: Fri, 12 Mar 2010 15:20:52 -0600 (CST) From: Mark Tinguely Message-Id: <201003122120.o2CLKqVQ090461@casselton.net> To: maksverver@geocities.com, tinguely@casselton.net In-Reply-To: <4B9A9CE0.2090509@geocities.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Fri, 12 Mar 2010 15:20:53 -0600 (CST) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 21:20:55 -0000 > > On 03/10/2010 07:07 PM, Mark Tinguely wrote: > > I believe there is still a path that md.pv_kva is not being zeroed > > before the page is freed. [..] We can prove this theory by placing a > > temporary printf statement or even better a panic in > > vm_page_free_toq(). > > I tried this, and it triggers immediately during boot, but I don't > really know what to do at the debugger prompt except produce a backtrace. > > Here's the complete log: > > Does this help? > > - Maks Verver. Thanks. Right now I have more questions about that dump than answers, but every clue helps. --Mark. From owner-freebsd-arm@FreeBSD.ORG Sat Mar 13 02:07:05 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 E4DDE1065673 for ; Sat, 13 Mar 2010 02:07:05 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id B4EDA8FC08 for ; Sat, 13 Mar 2010 02:07:05 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 15951E3D4F for ; Fri, 12 Mar 2010 21:07:05 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 12 Mar 2010 21:07:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=date:from:to:subject:message-id:in-reply-to:references:mime-version:content-type:content-transfer-encoding; s=smtpout; bh=dIzIng60axE4hk0nQrKCrzmR0fE=; b=ojy5VKhwGwdxagtRPR4PJn1iG32BPFsMxajUBWu8jplWzh6la9c0NvAY+ty3e1WLtLLcU431HtMHSflgtB2blCsj73BiTvsPN1csenGg9uF0l6lRQlVVdZEOvzIr3QaQNR1FtSCm2Drr1v1O7/m+UJ62wOuBrULmKZ4KGfCswmI= X-Sasl-enc: APVHNYYlIMX5640DJJkm7kctHpjt7/+dy2Zse+8MCVoK 1268446023 Received: from localhost (197.214.32.202.bf.2iij.net [202.32.214.197]) by mail.messagingengine.com (Postfix) with ESMTPA id 747123CEB2 for ; Fri, 12 Mar 2010 21:07:03 -0500 (EST) Date: Sat, 13 Mar 2010 11:06:39 +0900 From: Andrew Turner To: freebsd-arm@freebsd.org Message-ID: <20100313110639.5bf1175b@fubar.geek.nz> In-Reply-To: <20100303123440.2fb48f9a@fubar.geek.nz> References: <20100211223402.621a8c89@fubar.geek.nz> <20100303123440.2fb48f9a@fubar.geek.nz> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) X-Pirate: Arrrr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: New S3C24x0 patch 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: Sat, 13 Mar 2010 02:07:06 -0000 On Wed, 3 Mar 2010 12:34:40 +1300 Andrew Turner wrote: > I've posted a new patch at [1] taking into account the changes > suggested to me either via this list or privately. > > Andrew > > [1] > http://fubar.geek.nz/files/freebsd/s3c2xx0/freebsd-s3c24x0-20100227.diff Are there any issues people can see with this patch or is it able to be committed? Andrew From owner-freebsd-arm@FreeBSD.ORG Sat Mar 13 02:37:03 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 812AC1065675 for ; Sat, 13 Mar 2010 02:37:03 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3731A8FC08 for ; Sat, 13 Mar 2010 02:37:02 +0000 (UTC) Received: by gwj15 with SMTP id 15so782247gwj.13 for ; Fri, 12 Mar 2010 18:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=mNDPLshxo6j7Ahs7tfUFZir4QOKGbOZR9GTv8YOxgTw=; b=Gmx47LN9/EEM6arPnFjhiT74FQ++Kza1/LirKfyZCXGCM1WEJu8m6MRBsfKVRo34xz YHbqXvdCvW2hZuBK5SXko2kV2MVbzK6Wa8pFSFMjt6Ozk5egXZYnkRVOF42AYdCmKrO9 Jg+KOXn9uzsf7AcOMV5QqK+GJdTzeoUp7WYJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=P0ScFvuvo3aHjIfVjTCppbUZnyZ0lAeyTSo2VSetSJ8GJJS8Kx31rRuGhNi7Drdyc+ iYkj6wPs+6tRAq+yBUEq5btly8uTGeyANxCt1leuVw4Aj3DwvKoUAPdL+ozVyO+0ZKe0 M3C8Mb/MGY61/7OvKU0Ah/3j03FOd9vutvp1Y= Received: by 10.150.252.3 with SMTP id z3mr998478ybh.62.1268447822362; Fri, 12 Mar 2010 18:37:02 -0800 (PST) Received: from [192.168.11.61] (197.214.32.202.bf.2iij.net [202.32.214.197]) by mx.google.com with ESMTPS id 23sm627954yxe.56.2010.03.12.18.36.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Mar 2010 18:37:01 -0800 (PST) Sender: Rui Paulo Message-Id: <11F7FD2B-59F8-4E2F-869D-9B13D7D81117@FreeBSD.org> From: Rui Paulo To: Andrew Turner In-Reply-To: <20100313110639.5bf1175b@fubar.geek.nz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 13 Mar 2010 11:36:55 +0900 References: <20100211223402.621a8c89@fubar.geek.nz> <20100303123440.2fb48f9a@fubar.geek.nz> <20100313110639.5bf1175b@fubar.geek.nz> X-Mailer: Apple Mail (2.936) Cc: freebsd-arm@freebsd.org Subject: Re: New S3C24x0 patch 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: Sat, 13 Mar 2010 02:37:03 -0000 On 13 Mar 2010, at 11:06, Andrew Turner wrote: > On Wed, 3 Mar 2010 12:34:40 +1300 > Andrew Turner wrote: >> I've posted a new patch at [1] taking into account the changes >> suggested to me either via this list or privately. >> >> Andrew >> >> [1] >> http://fubar.geek.nz/files/freebsd/s3c2xx0/freebsd-s3c24x0-20100227.diff > > Are there any issues people can see with this patch or is it able to > be > committed? I was waiting for Warner to do it. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Sat Mar 13 03:56: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 C9B65106564A for ; Sat, 13 Mar 2010 03:56:52 +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 741798FC15 for ; Sat, 13 Mar 2010 03:56:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o2D3p0Eu077333; Fri, 12 Mar 2010 20:51:00 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 12 Mar 2010 20:51:08 -0700 (MST) Message-Id: <20100312.205108.1073903142004413004.imp@bsdimp.com> To: andrew@fubar.geek.nz From: "M. Warner Losh" In-Reply-To: <20100313110639.5bf1175b@fubar.geek.nz> References: <20100211223402.621a8c89@fubar.geek.nz> <20100303123440.2fb48f9a@fubar.geek.nz> <20100313110639.5bf1175b@fubar.geek.nz> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: New S3C24x0 patch 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: Sat, 13 Mar 2010 03:56:52 -0000 In message: <20100313110639.5bf1175b@fubar.geek.nz> Andrew Turner writes: : On Wed, 3 Mar 2010 12:34:40 +1300 : Andrew Turner wrote: : > I've posted a new patch at [1] taking into account the changes : > suggested to me either via this list or privately. : > : > Andrew : > : > [1] : > http://fubar.geek.nz/files/freebsd/s3c2xx0/freebsd-s3c24x0-20100227.diff : : Are there any issues people can see with this patch or is it able to be : committed? I think this can be committed. Warner From owner-freebsd-arm@FreeBSD.ORG Sat Mar 13 03:56:55 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 BC20C106566C; Sat, 13 Mar 2010 03:56:55 +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 7CE398FC08; Sat, 13 Mar 2010 03:56:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o2D3pEkk077334; Fri, 12 Mar 2010 20:51:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 12 Mar 2010 20:51:21 -0700 (MST) Message-Id: <20100312.205121.370705936310773363.imp@bsdimp.com> To: rpaulo@freebsd.org From: "M. Warner Losh" In-Reply-To: <11F7FD2B-59F8-4E2F-869D-9B13D7D81117@FreeBSD.org> References: <20100303123440.2fb48f9a@fubar.geek.nz> <20100313110639.5bf1175b@fubar.geek.nz> <11F7FD2B-59F8-4E2F-869D-9B13D7D81117@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: New S3C24x0 patch 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: Sat, 13 Mar 2010 03:56:55 -0000 In message: <11F7FD2B-59F8-4E2F-869D-9B13D7D81117@FreeBSD.org> Rui Paulo writes: : On 13 Mar 2010, at 11:06, Andrew Turner wrote: : : > On Wed, 3 Mar 2010 12:34:40 +1300 : > Andrew Turner wrote: : >> I've posted a new patch at [1] taking into account the changes : >> suggested to me either via this list or privately. : >> : >> Andrew : >> : >> [1] : >> http://fubar.geek.nz/files/freebsd/s3c2xx0/freebsd-s3c24x0-20100227.diff : > : > Are there any issues people can see with this patch or is it able to : > be : > committed? : : I was waiting for Warner to do it. I'll do it this weekend. Warner