Which way to store log in flash on mpc8xx?

[Fillod Stephane]

David Jander wrote:
[..]
>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!!

Strange. I heard a different song here[1], but haven't checked the fact 
myself. From what I've seen, mtd/jffs2 is faster on 2.6.x than 2.4.x.

[1] http://www.denx.de/wiki/Know/Linux24vs26

>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 

See the patch past my sig. It changes the timeout from couple ms to 1
second.
RTAI & Xenomai users should need it. IMHO, the WANT_SHORT_WTIMEOUT
embraced code should simply go away, or get a decent explanation.

>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)

Regards,
-- 
Stephane


--- drivers/mtd/chips/cfi_cmdset_0002.c	12 Sep 2005 09:27:29 -0000
+++ drivers/mtd/chips/cfi_cmdset_0002.c	29 Nov 2005 15:30:30 -0000
@@ -935,6 +935,12 @@
 	struct cfi_private *cfi = map->fldrv_priv;
 	unsigned long timeo = jiffies + HZ;
 	/*
+	 * Hardware errors should be infrequent,
+	 * so a short timeout is of no benefit.
+	 * And it just hurts with RTAI.
+	 */
+#ifdef WANT_SHORT_WTIMEOUT
+	/*
 	 * We use a 1ms + 1 jiffies generic timeout for writes (most
devices
 	 * have a max write time of a few hundreds usec). However, we
should
 	 * use the maximum timeout value given by the chip at probe time
@@ -944,6 +950,7 @@
 	 * timeout of 0 jiffies if HZ is smaller than 1000.
 	 */
 	unsigned long uWriteTimeout = ( HZ / 1000 ) + 1;
+#endif
 	int ret = 0;
 	map_word oldd;
 	int retry_cnt = 0;
@@ -987,8 +994,10 @@
 				adr, map_bankwidth(map),
 				chip->word_write_time);
 
+#ifdef WANT_SHORT_WTIMEOUT
 	/* See comment above for timeout value. */
 	timeo = jiffies + uWriteTimeout; 
+#endif
 	for (;;) {
 		if (chip->state != FL_WRITING) {
 			/* Someone's suspended the write. Sleep */
@@ -1189,8 +1198,15 @@
 {
 	struct cfi_private *cfi = map->fldrv_priv;
 	unsigned long timeo = jiffies + HZ;
+	/*
+	 * Hardware errors should be infrequent,
+	 * so a short timeout is of no benefit.
+	 * And it just hurts with RTAI.
+	 */
+#ifdef WANT_SHORT_WTIMEOUT
 	/* see comments in do_write_oneword() regarding uWriteTimeo. */
 	unsigned long uWriteTimeout = ( HZ / 1000 ) + 1;
+#endif
 	int ret = -EIO;
 	unsigned long cmd_adr;
 	int z, words;
@@ -1248,7 +1264,9 @@
 				adr, map_bankwidth(map),
 				chip->word_write_time);
 
+#ifdef WANT_SHORT_WTIMEOUT
 	timeo = jiffies + uWriteTimeout; 
+#endif
 		
 	for (;;) {
 		if (chip->state != FL_WRITING) {