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