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.