Date: Sun, 7 Mar 2010 21:30:55 +0100 From: Rafal Jaworowski <raj@semihalf.com> To: Maks Verver <maksverver@geocities.com> Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable Message-ID: <FB81E027-0CCC-4DF6-A29F-88920A39556B@semihalf.com> In-Reply-To: <4B9404DE.70607@geocities.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FB81E027-0CCC-4DF6-A29F-88920A39556B>