From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 04:16:22 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9580C4EA for ; Thu, 27 Dec 2012 04:16:22 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABA08FC08 for ; Thu, 27 Dec 2012 04:16:21 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1To4tF-000JET-T0; Wed, 26 Dec 2012 20:16:20 -0800 Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Oleksandr Tymoshenko X-Priority: 3 In-Reply-To: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> Date: Wed, 26 Dec 2012 20:16:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> To: Daisuke Aoyama X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-12-26, at 7:52 PM, Daisuke Aoyama wrote: >> PTE sync - related part, Im not sure it's strictly required. We use WT caches for page tables >> so we should be OK without implicit sync operations for them. I hope somebody >> more clueful can confirm/disprove this. > > Some digging, I notice "Invalidate Entire Instruction Cache" works without segfault. > So, Invalidate D-cache is no effect :) > > It seems following should work for this issue: > > mov r0, #0 > mcr p15, 0, r0, c7, c5, 0 /* Invalidate Entire Instruction Cache */ > mcr p15, 0, r0, c7, c10, 4 /* Data Synchronization Barrier */ > > Try this code instead of CF_ICACHE_SYNC. > I don't know side effect of Invalidate I-cache, but it works. > Also I don't know whether DSB is required or not. > > For test, using NFS or HDD/SDD is BAD idea for system stress. > You must use SD(mmc) or USB memory. Serial console is recommended for interrupt test. > Here is simple test from serial console: > > # rm -rf /var/db/portsnap /usr/ports > # mkdir /var/db/portsnap > # portsnap fetch > # portsnap extract > # cd /usr/ports/shells/bash > # make BATCH=y > > If your kernel is really stable, it should finish without any problems with SD/mmc. > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Dec 2012 04:16:22 -0000 On 2012-12-26, at 7:52 PM, Daisuke Aoyama wrote: >> PTE sync - related part, Im not sure it's strictly required. We use = WT caches for page tables >> so we should be OK without implicit sync operations for them. I hope = somebody >> more clueful can confirm/disprove this. >=20 > Some digging, I notice "Invalidate Entire Instruction Cache" works = without segfault. > So, Invalidate D-cache is no effect :) >=20 > It seems following should work for this issue: >=20 > mov r0, #0 > mcr p15, 0, r0, c7, c5, 0 /* Invalidate Entire = Instruction Cache */ > mcr p15, 0, r0, c7, c10, 4 /* Data Synchronization = Barrier */ >=20 > Try this code instead of CF_ICACHE_SYNC. > I don't know side effect of Invalidate I-cache, but it works. > Also I don't know whether DSB is required or not. >=20 > For test, using NFS or HDD/SDD is BAD idea for system stress. > You must use SD(mmc) or USB memory. Serial console is recommended for = interrupt test. > Here is simple test from serial console: >=20 > # rm -rf /var/db/portsnap /usr/ports > # mkdir /var/db/portsnap > # portsnap fetch > # portsnap extract > # cd /usr/ports/shells/bash > # make BATCH=3Dy >=20 > If your kernel is really stable, it should finish without any problems = with SD/mmc. >=20 Hmm, I saw problems with i-caches with kernel with WB cache enabled = instead of WT.=20 This patch fixed it for me: http://people.freebsd.org/~gonzo/arm/patches/pmapv6-icache.diff It invalidates i-caches only when new mapping is created, not on every = switch so=20 it should be less taxing on performance. Could you test it on your setup?=20=