Anyone using marvell 64420 system controller

Anyone using marvell 64420 system controller

[Fuxin Zhang]

hi,

  We have been puzzled by the strange problems with our new board with
marvell 64420 for nearly one month.

The board is unstable in linux. Using a 2.6.14 kernel it dies very
easily with file system operations;with a 2.4.22 kernel it can survive
a "cp -a /usr /usr1", but diffing two identical files with sizes > 50M
often mistakely reports difference.The diff result is often 32 bytes,but
the first byte is not cache line aligned(in fact,almost always
%cachelinesize == 1).

The results remain true even with ramdisk only and any other pci device
removed from the board. The same mips CPU works well on other boards,
the same kernel with different platform chosen is very stable too. So I
tend to doubt the bridge or its DDR controller.( Is there any possiblity
of platform related code that lead to such problem? )


If anyone has experiences on this chip, could you point us some way out?
It seems we cannot easily reach the marvell's core developers.

Thanks a lot.

Re: Anyone using marvell 64420 system controller

[Fuxin Zhang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1406 bytes --]

I forget to mention that in boot loader things look like quite stable:
memory test is ok(we ported memtest86), loading big files over the
network is ok, gzip/unzip/diff a 40MB file is ok too.

And if we turn on memory debug for slab allocator on 2.6, we often meet
random slab corruptions. It looks like some memory area will be
mysteriously changed.

Fuxin Zhang дµÀ:
> hi,
> 
>   We have been puzzled by the strange problems with our new board with
> marvell 64420 for nearly one month.
> 
> The board is unstable in linux. Using a 2.6.14 kernel it dies very
> easily with file system operations;with a 2.4.22 kernel it can survive
> a "cp -a /usr /usr1", but diffing two identical files with sizes > 50M
> often mistakely reports difference.The diff result is often 32 bytes,but
> the first byte is not cache line aligned(in fact,almost always
> %cachelinesize == 1).
> 
> The results remain true even with ramdisk only and any other pci device
> removed from the board. The same mips CPU works well on other boards,
> the same kernel with different platform chosen is very stable too. So I
> tend to doubt the bridge or its DDR controller.( Is there any possiblity
> of platform related code that lead to such problem? )
> 
> 
> If anyone has experiences on this chip, could you point us some way out?
> It seems we cannot easily reach the marvell's core developers.
> 
> Thanks a lot.
> 
> 
> 
> 
>