When I was tracking down a timing problem on our SDRAM I found that doing a native compile of glibc over NFS seems to be a very good memory test.
> -----Original Message----- > From: linuxppc-embedded-bounces+runet=innovsys.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+runet=innovsys.com at ozlabs.or > g] On Behalf Of Kenneth Poole > Sent: Wednesday, April 19, 2006 07:59 > To: linuxppc-embedded at ozlabs.org > Subject: kernel access of bad area, sig: 11 ( mpc852t) > > > >>> Hi, > > >>> Im having problem porting linux kernel 2.4.21 to our > mpc852T custom > > >>> board.The kernel > > >>> panics randomly with sig 11. > > >>> The board boots up fine and we also get to the > prompt.When we open 3-4 > > >>> telnet sessions > > >>> and try to run some command the kernel panics.This is completely > > >>> random.Sometimes it > > >>> even panics before opening the telnet session. > > >>> > > > >>> <oops dump snipped> > > >>> > > >>You almost certainly have SDRAM problems. If you have > thoroughly checked > > >>out the > > >>complete address range statically, remember that burst > accesses will not > > >>occur until the > > >>cache is turned on, so your problem may be with bursting. > But you can also > > >>have severe > > >>problems like a missing address line and linux still run > for a few seconds. > > >> > > >>Mark Chambers > > >We've checked the SDRAM. The timings (UPM) look fine. The problem > > >however is that linux does not hang until after a few processes are > > >started. > > >If we boot to linux and leave it as it is, everything is fine and the > > >board remains working. However each time a few processes (4-5 telnet > > >sessions for eg.) are started the system either panics or hangs (goes > > >dead). > > >Thanks in advance, > > >Akshay > > We have been experiencing this same issue with random boards > in production. The exact same version of software will run > for months on other instances of the exact same board design, > but a few percent get 'random' trap 300s. When they do occur, > it's only after Linux has booted and address translation and > caching are turned on. Examining the oops-es and memory shows > that some location in SDRAM has a bogus value, but I don't > have the tools to trace back how it got that way. > > I have ported a rigorous moving-inversions memory test into > our firmware, and have run it extensively across the entire > SDRAM address space (the test code executes from flash). I > have let this test run continuously for hours and hours, but > never found a memory problem. Unfortunately, I do not have > test software that enables the MMU address translation or > caching, so as Mark said, I can't test memory using bursting. > Our hardware engineers have reviewed the designs very > carefully and are quite confident that there is plenty of > margin in the memory timing. Signal quality has also been > carefully checked. > > Our manufacturing people have replaced the CPU on some of > these boards, and the problem went away. > > If anyone else on the mailing list has experienced this > issue, or has developed a virtual address memory test, please > let us know. > > Ken Poole > > > > > >
