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.