In message [off-list ref] 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@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.
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 [off-list ref] wrote:
In message [off-list ref] you wrote:
quoted
Is there something like memtest86 for linux-ppc (i.e. written in portab=
le 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.
quoted
Hmm, but.... there is no data corruption. I have not seen one file on f=
lash
quoted
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.
quoted
That commit only changed 3 files, non of them directly related to jffs2=
code,
This is correct.
quoted
and only seemed to add support for FUJITSU flash chips. What am I missi=
ng?
quoted
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@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@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Hi,
On Tuesday 29 November 2005 02:06, David Ho wrote:
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.
I have done almost the same (compiling Perl didn't succeed because of an
out-of memory condition), and never had any other reason to suspect hardware
problems.
After getting some advice from peoble at mtd-list, I switched to 2.6.14 for
our new developments, and jffs2 seems a lot more stable now. I can only
recommend you to consider switching. Besides consuming a little more RAM and
Flash, 2.6.14 is miles ahead in terms of almost anything else, plus it's a
bit faster on 8xx than 2.4.25!!
I have to warn you though, that it still seems not to be as rock-solid as one
might want for an embedded system: We have a stress test running for a few
weeks now simulating power-failures during writes to files on jffs2, and mtd
has some occasional hick-ups. Those hick-ups seem to be far less serious than
gc.c crashing, but we will have to take them into account in our application.
This is the situation: Sometimes the test application crashes giving a
write-error on the mtd device, preceded by an error message from the
mtd-driver (and jffs2, but the problem seems to come from mtd). The error
message is like "MTD do_write_buffer(): software timeout", which normally
means a flash programming error, most probably due to sector beeing worn out,
but I don't think that is the case, since those problems began appearing
quite early and went away all by them selves. Flash doesn't magically "fix"
itself over time, does it?
Maybe it's a problem in the AMD flash driver (our device is a Spansion
Mirror-bit S29GL256M11)
David: have you gotten any new insights since?
Yes, see above.
Please keep me informed if you get to know something more about the
problem ;-)
If you want more detail about what tests we are doing, and the problems we had
so far, feel free to ask, or read my posts to the MTD list. Right now its
46268 power-cycles and counting.
Greetings,
--
David Jander
Protonic Holland.