Hi, just catching up on this problem as I have another unit that showed the same symptom. My system looks like this
MPC852T 128Mbytes SDRAM 64Mbytes Flash Flash partitions 2*1.25Mbytes partitions for Kernel 61.5Mbytes for rootfs and applications. Remaining 1Mbyte for U-boot, u-boot env and spare. I get that same problem as well. kernel BUG at gc.c: 139 I have compiled Perl, Openssl, Openssh, etc running NFS so SDRAM is definitely not the issue. David: have you gotten any new insights since? Regards, David Ho On 9/20/05, Wolfgang Denk <wd at denx.de> wrote: > In message <200509201117.40454.david.jander at protonic.nl> you wrote: > > > > Is there something like memtest86 for linux-ppc (i.e. written in portable > > C)? > > Yes, there is. Run the system with root file system mounted over NFS, > and then put some load on the system, like by compiling the linux > kernel on the target. Anything else which adds DMA load does not > hurt, either. In such a situation, with a lots of context switches, > stress on the memory management system and having a lots of DMA > traffic going on you may see some memory problems. Unfortunately none > of the standard memory tests will catch thse, as the tests usually > provide only plain read / write accesses, while the problems show up > only in burst mode, i. e. when filling the caches and/or doing DMA. > > There is an attempt of a burst mode memory test in the U-Boot code, > but I have to admit that I didn't work to show the exact problem on > the system it was written for. > > > Hmm, but.... there is no data corruption. I have not seen one file on flash > > that had other data than intended, and that inspite of the GC freaking out. > > Maybe there is no corruption of the data in flash. But are you sure > that correct data are loaded to and read from RAM? We had a similar > problem on a board where data got corrupted only when doing a lot of > transfers flash->RAM. > > > That commit only changed 3 files, non of them directly related to jffs2 > > code, > > This is correct. > > > and only seemed to add support for FUJITSU flash chips. What am I missing? > > MTD developers say that cvs from march-2005 _is_ broken, so there must be > > some > > Yes, of course it's broken. Like all computer code. There are a > couple of known issues (especially with NAND flash), but I don't > think they could explain the type of problems you are seeing. > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de > Einstein argued that there must be simplified explanations of nature, > because God is not capricious or arbitrary. No such faith comforts > the software engineer. - Fred Brooks, Jr. > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded >
