Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 07 Mar 2010 22:38:36 +0100
From:      Maks Verver <maksverver@geocities.com>
To:        freebsd-arm@freebsd.org
Subject:   Re: Performance of SheevaPlug on 8-stable
Message-ID:  <4B941CDC.4010101@geocities.com>
In-Reply-To: <FB81E027-0CCC-4DF6-A29F-88920A39556B@semihalf.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> <FB81E027-0CCC-4DF6-A29F-88920A39556B@semihalf.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B941CDC.4010101>