Brian,

I know you are aware of this but I *always* experience cache coherency
problems with the GT64260A when Sysclk/Tclk are anything above 100MHz
and I believe that your board is clocked over that.  Try a 100MHz
crystal and see if the problem goes away.

Mark
--
Dan Malek wrote:

Brian Waite wrote:

quoted

.... The memory controller (gt64260) seems to be

quoted

doing something very wrong and it is thought to be a cache coherency
issue.

The problem is cache coherency is central to the operation of processor
bus.  One possibility, especially in the example you described, is the gt
is generating incorrect cache coherency control cycles on the bus.
Disabling
the processor cache isn't going to affect this.

quoted

So to prove this, I was asked to try running without any sort of cache.

Make sure you disable it in the memory controller as well.

quoted

Hopefully between Gary's information and yours, Dan I can convince
people
that it is futile.

Linux is a very poor diagnostic tool.  When I run Linux and discover this
type of problem, I reduce it down into a non-Linux diagnostic that can
generate the same type of bus cycles.  That way you can just flash it
into
rom and let some hardware engineer run it over and over without having to
boot up something as complex as Linux and sorting through millions of
bus cycles for the failure mode.  With these types of problems you have
to determine exactly what causes the failure.  Since the processor hangs
so completely it should be easy to see the condition of the failure.  If
it is a memory controller timing problem, you should see exactly what
failed and it should be clear how to program the controller to correct
it.

Of course, like Ben said, check the errata.

Good Luck.


    -- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/