Which way to store log in flash on mpc8xx?

Which way to store log in flash on mpc8xx?

[David Jander]

Hi all,

I am looking for a reliable way to store logfiles in flash. The logfiles are 
written by syslogd.
The problem is that I am running on a MPC8xx processor, and kernel 2.6 is not 
quite there yet for that processor, so I have to stick with 2.4.
Kernel of choice seems to be denx linuxppc_2_4_devel, but I cannot trust the 
version of jffs2 used in that kernel anymore. Somtimes gc.c crashes with a 
BUG() in line 139, and sometimes processes are frozen for a looong time 
waiting for GC. I have debugged that problem a little bit, and definitely, 
the FLASH access works ok, and the chip is new. No CRC- or read-errors, but 
still gc.c crashes.
The version of mtd/jffs2 drivers in that kernel seem to be from march/2005 cvs 
code, but when I read the following, I get even more scared:
http://www.linux-mtd.infradead.org/source.html#kernelversions

So, I need something different. jffs (1) maybe ?
This must be a very common task (to store logfiles in flash), but I just can't 
seem to find the right way to do it.

Any advice is highly appreciated.

Sincerely,

-- 
David Jander
Protonic Holland.

Re: Which way to store log in flash on mpc8xx?

[Frank]

--- David JandJandervidaviddjandertprotonic nlote:

> 
> Hi all,
> 
> I am looking for a reliable way to store logflogfilesflash.
> The logflogfiles 
> written by syslsyslogd The problem is that I am running on a
MPC8MPCprocessor, and
> kernel 2.6 is not 
> quite there yet for that processor, so I have to stick with
> 2.4.
> Kernel of choice seems to be denxdenxulinuxppc_devedevelt I
> cannot trust the 
> version of jffsjffsed in that kernel anymore. SomtSomtimescgc>
crashes with a 
> BUG() in line 139, and sometimes processes are frozen for a
> looolooonge 
> waiting for GC. GChave debugged that problem a little bit, and
> definitely, 
> the FLASH access works ok, okd the chip is new. No CRC-CRC
> read-errors, but 
> still gc.cgcrashes.
> The version of mtd/mtdsjffsivers in that kernel seem to be
> from march/2005 cvs cvs code, but when I read the following, I
get even more scared:
>
httphttpww.wwwulinux.mtdrinfradead/source.htmlhtmlnkernelversions
> So, I need something different. jffsjffs maybe ?
> This must be a very common task (to store logflogfilesflash),
> but I just can't 
> seem to find the right way to do it.
> 
> Any advice is highly appreciated.
> 
> Sincerely,
> 
> -- 
> David JandJanderProtProtonicland.

I'm using JFFSJFFS a 860 based board (to store log files
amonamongster things) and haven't seen any of the problems
you're expeexperiencing I were you, I would double check my
configuration settings...
> _______________________________________________
> LinuLinuxppcedded mailing list
> LinuLinuxppcedded@ozlaozlabs
> httphttpszlaozlabs/mailman/listlistinfoulinuxppcedded
> 


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: Which way to store log in flash on mpc8xx?

[Wolfgang Denk]

In message <200509191155.36540.david.jander@protonic.nl> you wrote:
> 
> Kernel of choice seems to be denx linuxppc_2_4_devel, but I cannot trust the 
> version of jffs2 used in that kernel anymore. Somtimes gc.c crashes with a 
> BUG() in line 139, and sometimes processes are frozen for a looong time 

Can you provide a little more details? The MTD / JFFS2 code  in  this
kernel  is  not too old, andwe use it in a couple of projects without
such problems.

> waiting for GC. I have debugged that problem a little bit, and definitely, 
> the FLASH access works ok, and the chip is new. No CRC- or read-errors, but 
> still gc.c crashes.

Can you provide soem more information for debugging?

> The version of mtd/jffs2 drivers in that kernel seem to be from march/2005 cvs 
> code, but when I read the following, I get even more scared:
> http://www.linux-mtd.infradead.org/source.html#kernelversions

Don't worry. We backported the MTD / JFFS2 code. See the  history  of
changes on our CVS or git server.

> This must be a very common task (to store logfiles in flash), but I just can't 
> seem to find the right way to do it.

Note that log files may cause a lot of trouble  when  using  a  JFFS2
file  system. Youmay want to addd a buffering layer, like pramfs in a
dedicated RAM area (SRAM ideally).


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
Never underestimate the bandwidth of a station wagon full of tapes.
                                -- Dr. Warren Jackson, Director, UTCS

Re: Which way to store log in flash on mpc8xx?

[David Jander]

Hi again,

Thanks for helping,

On Monday 19 September 2005 17:37, Wolfgang Denk wrote:
>[...]
> Can you provide a little more details? The MTD / JFFS2 code  in  this
> kernel  is  not too old, andwe use it in a couple of projects without
> such problems.

Ok, good you asked, because I am willing to debug the problem until I get to 
the point where it fails, but I will need help, because I am not at home in 
jffs2 source-code nor its CVS history.

Here are more details:

Kernel: Denx CVS from around july 2005 or something. AFAIK there are no 
further modifications other than BSP-specific stuff to the MTD code since 
that day, so I won't bother upgrading any further right now.

Hardware: MPC852T custom board with a 32Mbyte mirror-bit flash-chip (x16 bus)

Software: System based on ELDK-3.1.1. Intended flash-layout and use:
  rootfs     : 10Mb, ro, hardly ever changed
  app        : 6Mb, ro, changed on software-upgrade by replacing partition.
  log+config : 12Mb, rw

The log+config partition is extremely oversized, because we are aware of the 
inefficiency of jffs2 for such purposes, we have the available space and we 
want to stay out of trouble. Syslog writes to 4 log-files which are limited 
in size to 50..100kbyte each. Logs are then rotated and one rotated copy is 
kept. Maximum flash use is around 800kbyte for logs + 50kbyte for config 
data. On a 12Mbyte partition, that shouldn't get us into trouble AFAIK.

> > waiting for GC. I have debugged that problem a little bit, and
> > definitely, the FLASH access works ok, and the chip is new. No CRC- or
> > read-errors, but still gc.c crashes.
>
> Can you provide soem more information for debugging?

Unfortunately right now I don't have debug messages, because since I installed 
a kernel with debugging turned on in the jffs2 driver, the problem hasn't 
repeated. I am working on that.

What happened: System boots, all fs are mounted. The first app that writes 
something to the log-partition (in this case a config file that is 
overwritten) causes the GC thread for that partition to crash with a BUG() in 
line 139 of gc.c, and the application freezes forever. Since GC is dead, all 
further write-accesses to that partition also hang forever.

The problem seems to ocurr after a few times power-cycling the board. We never 
intended it to shut-down nicely, if it is at all ever shut-down, so it must 
be able to survive quite a few power-cycles without breaking.

After a few more power-cycles, the problem is gone again. Each time GC kicks 
in, it does something, but it crashes before finishing the job, so each time 
the numbers reported by the printk() in line 138 change, and eventually it 
work again.

My big question: Is it at all possible that gc.c comes to that BUG() in line 
139 because of anything other than a bug in jffs2-code?
I mean, if hardware really was a problem, then I should also get at least 
CRC-errors from jffs2, shouldn't I? IMHO at least, jffs2 should be robust 
enough to not crash on flash-errors, shouldn't it?

Also, I am pretty certain that the hardware is good.... but you never know...

> > The version of mtd/jffs2 drivers in that kernel seem to be from
> > march/2005 cvs code, but when I read the following, I get even more
> > scared:
> > http://www.linux-mtd.infradead.org/source.html#kernelversions
>
> Don't worry. We backported the MTD / JFFS2 code. See the  history  of
> changes on our CVS or git server.

I am having trouble finding the right history, but that could be due to the 
fact that I am not very good at CVS (we use subversion which is slightly 
different) ;-)
The logs of almost all files in fs/jffs2/ which I have say that the actual 
version corresponds to the CVS-snapshot of March 13, 2005, and that the 
previous version of April 2004 is broken.
Which files were modified _after_ March 13, 2005? 
(A hint to what command options or tools to use to browse cvs-logs more easily 
at this point is appreciated... I am using cervisia).

> > This must be a very common task (to store logfiles in flash), but I just
> > can't seem to find the right way to do it.
>
> Note that log files may cause a lot of trouble  when  using  a  JFFS2
> file  system. Youmay want to addd a buffering layer, like pramfs in a
> dedicated RAM area (SRAM ideally).

I know about the problems jffs2 has with logfiles and alikes. I am still 
thinking about what would be the most robust way of coping with this, and 
until now, oversized partitions with log-rotation on size seems to do the 
trick. I don't want to loose log-data on power-loss so I don't feel so 
comfortable with buffering much of it in RAM.

Best Regards,

-- 
David Jander
Protonic Holland.

Re: Which way to store log in flash on mpc8xx?

[Shawn Jin]

> > This must be a very common task (to store logfiles in flash), but I jus=
t can't
> > seem to find the right way to do it.
>=20
> Note that log files may cause a lot of trouble  when  using  a  JFFS2
> file  system. Youmay want to addd a buffering layer, like pramfs in a
> dedicated RAM area (SRAM ideally).

What's the trouble caused by log files when using a JFFS2? I'm not
aware of that. Any pointers to where I should look into are much
appreciated.

Best regards,
-Shawn.

Re: Which way to store log in flash on mpc8xx?

[Jörn Engel]

On Mon, 19 September 2005 11:40:05 -0700, Shawn Jin wrote:
> 
> > > This must be a very common task (to store logfiles in flash), but I just can't
> > > seem to find the right way to do it.
> > 
> > Note that log files may cause a lot of trouble  when  using  a  JFFS2
> > file  system. Youmay want to addd a buffering layer, like pramfs in a
> > dedicated RAM area (SRAM ideally).
> 
> What's the trouble caused by log files when using a JFFS2? I'm not
> aware of that. Any pointers to where I should look into are much
> appreciated.

I guess this should become a FAQ item.

JFFS2 creates one or more nodes whenever sys_write is called.
Unbuffered log entries are usually quite small, so a single node is
written.  Let's assume the worst case, just for fun, writes of a
single by.

Now, each node is prepended by a struct jffs2_raw_inode of 64 bytes.
So you're causing the first problem:
1. Up to 65x the raw file data is written to flash.

Which means you waste bus bandwidth, was flash space and waste flash
lifetime.  After GC, most of those nodes should get combined to 4k
nodes (plus 64 bytes for the header).  Now, JFFS2 also requires an
in-memory structure per node, the struct jffs2_raw_node_ref, weighing
in at 16 or 24 bytes, if you have a 32bit or 64bit arch.  Those will
cost you precious memory:
2. Up to 24x the raw file data is required in DRAM.

Next problem is with GC accounting.  JFFS2 only differentiates between
valid and obsolete data.  After writing a huge logfile, all of its
nodes are still valid.  Therefore GC will never try to GC such nodes,
unless they happen to sit in an erase block with a lot of obsolete
data.  And even then, they could get copied as-is, with no combining.
3. JFFS2 GC is too stupid to detect miniature nodes and combine them.

So, your problem 1 and 2 will not go away if you wait long enough.
Renaming the log file also won't help.  The only cure would be to
*copy* it to the new location and delete the original file afterwards.
Or - alternatively - to fix JFFS2 GC and send a patch.
Or - as already proposed - by writing in larger chunks in the first
place.

If you decide to fix JFFS2 GC, I'd be happy to review the patches and
merge them if deemed worthy.

Jörn

-- 
My second remark is that our intellectual powers are rather geared to
master static relations and that our powers to visualize processes
evolving in time are relatively poorly developed.
-- Edsger W. Dijkstra

Re: Which way to store log in flash on mpc8xx?

[Wolfgang Denk]

In message <200509191926.12736.david.jander@protonic.nl> you wrote:
> 
> What happened: System boots, all fs are mounted. The first app that writes 
> something to the log-partition (in this case a config file that is 
> overwritten) causes the GC thread for that partition to crash with a BUG() in 
> line 139 of gc.c, and the application freezes forever. Since GC is dead, all 
> further write-accesses to that partition also hang forever.

Are you 100% sure your system is stable and wihout any memory errors?
Never seen any other erros or crashes?

> My big question: Is it at all possible that gc.c comes to that BUG() in line 
> 139 because of anything other than a bug in jffs2-code?

Yes, for example when your  SDRAM  initialization  is  broken  and/or
other memory corruption happens.

> I mean, if hardware really was a problem, then I should also get at least 
> CRC-errors from jffs2, shouldn't I? IMHO at least, jffs2 should be robust 
> enough to not crash on flash-errors, shouldn't it?

I don't think it's a flash error. If there is data  corruption,  then
it's more likely the SDRAM.

> The logs of almost all files in fs/jffs2/ which I have say that the actual 
> version corresponds to the CVS-snapshot of March 13, 2005, and that the 
> previous version of April 2004 is broken.
> Which files were modified _after_ March 13, 2005? 
> (A hint to what command options or tools to use to browse cvs-logs more easily 
> at this point is appreciated... I am using cervisia).

cvsps is really helpful, see http://www.cobite.com/cvsps/cvsps-2.1.tar.gz

Also there are web interfaces to our kernel tree;
for CVS see
	http://81.169.171.120/cgi-bin/cvsweb/
for git see
	http://81.169.171.120/cgi-bin/gitweb.cgi

Make sure to use at least the version tagged as LABEL_2005_05_09_1245
or later.

> I know about the problems jffs2 has with logfiles and alikes. I am still 
> thinking about what would be the most robust way of coping with this, and 
> until now, oversized partitions with log-rotation on size seems to do the 
> trick. I don't want to loose log-data on power-loss so I don't feel so 
> comfortable with buffering much of it in RAM.

The problem with your approach is the number of  erase  cycles  which
will cause the flash to die sooner than you may want.

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
A dog always bit deepest on the veterinary hand.
                                    - Terry Pratchett, _Wyrd Sisters_

Re: Which way to store log in flash on mpc8xx?

[Wolfgang Denk]

In message <c3d0340b050919114040d0a0fe@mail.gmail.com> you wrote:
>
> What's the trouble caused by log files when using a JFFS2? I'm not
> aware of that. Any pointers to where I should look into are much
> appreciated.

Please see the linux-mtd web site and/or MTD  mailing  list  archives
for  details.  JFFS2 works excellent with files that are written once
(or with only a few write() calls. Logfiles typically  grow  forever,
by  many,  many  small  chunks  of  data  appended  in  many  write()
operations - this is kind of killer application for JFFS2.

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
"I find this a nice feature but it is not according to  the  documen-
tation. Or is it a BUG?"   "Let's call it an accidental feature. :-)"
                       - Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>

Re: Which way to store log in flash on mpc8xx?

[David Jander]

Hi again,

On Monday 19 September 2005 21:21, Wolfgang Denk wrote:
>[...]
> Are you 100% sure your system is stable and wihout any memory errors?
> Never seen any other erros or crashes?

It has been running for several weeks without reboot processing data, and we 
have never had any other strange things, nor data corruption, crashes, or 
whatever.

> > My big question: Is it at all possible that gc.c comes to that BUG() in
> > line 139 because of anything other than a bug in jffs2-code?
>
> Yes, for example when your  SDRAM  initialization  is  broken  and/or
> other memory corruption happens.

Then you would expect to have other symptoms too, don't you? Well, we don't 
have any other symptoms of SDRAM errors. Although, I have seen PC's with 
faulty SDRAM that behave as if the HD was broken, but the fine tool 
"memtest86" finally revealed the truth ;-)
Is there something like memtest86 for linux-ppc (i.e. written in portable C)?

>[...]
> I don't think it's a flash error. If there is data  corruption,  then
> it's more likely the SDRAM.

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.

> > The logs of almost all files in fs/jffs2/ which I have say that the
> > actual version corresponds to the CVS-snapshot of March 13, 2005, and
> > that the previous version of April 2004 is broken.
> > Which files were modified _after_ March 13, 2005?
> > (A hint to what command options or tools to use to browse cvs-logs more
> > easily at this point is appreciated... I am using cervisia).
>
> cvsps is really helpful, see http://www.cobite.com/cvsps/cvsps-2.1.tar.gz
>
> Also there are web interfaces to our kernel tree;
> for CVS see
> 	http://81.169.171.120/cgi-bin/cvsweb/
> for git see
> 	http://81.169.171.120/cgi-bin/gitweb.cgi

Thanks for the tips. The gitweb interface looked quite impressive!

> Make sure to use at least the version tagged as LABEL_2005_05_09_1245
> or later.

We have that version. I have been trying to figure out what changed up until 
that label, but the only thing I found that looked relevant was: 
"Re-implement PatchSets 260, 263 and 303"
That commit only changed 3 files, non of them directly related to jffs2 code, 
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 
evident bug-fixes in your tree since then.... otherwise it is still broken 
(whatever it was).
Of course, maybe I'm just blind ;-)

> > I know about the problems jffs2 has with logfiles and alikes. I am still
> > thinking about what would be the most robust way of coping with this, and
> > until now, oversized partitions with log-rotation on size seems to do the
> > trick. I don't want to loose log-data on power-loss so I don't feel so
> > comfortable with buffering much of it in RAM.
>
> The problem with your approach is the number of  erase  cycles  which
> will cause the flash to die sooner than you may want.

That's true, but under normal use, you'll have maybe 5..10 lines a day added 
to a given logfile, maybe even less, and since the partition is relatively 
huge, wear-levelling in the jffs2 driver should do the obvious I believe.
It's not optimal, but it should work reliably AFAICT.

Regards,

-- 
David Jander
Protonic Holland.

Re: Which way to store log in flash on mpc8xx?

[Wolfgang Denk]

In message <200509201117.40454.david.jander@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@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.

RE: Which way to store log in flash on mpc8xx?

[Eli Brin]

Hello David,

Wolfgang wrote:
>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.

If you want to have some fun, and stress the platform, compile and run (via
NFS) Crafty, an open source Linux chess porgram.

We did so on our 8xx target and it plays very well...

Best regards,
Eli Brin

Re: Which way to store log in flash on mpc8xx?

[David Ho]

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@denx.de> wrote:
> In message <200509201117.40454.david.jander@protonic.nl> you wrote:
> >
> > 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.
>
> > Hmm, but.... there is no data corruption. I have not seen one file on f=
lash
> > 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 missi=
ng?
> > 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
>

Re: Which way to store log in flash on mpc8xx?

[David Jander]

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.

RE: 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=20
>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=20
>Flash, 2.6.14 is miles ahead in terms of almost anything else, plus
it's a=20
>bit faster on 8xx than 2.4.25!!

Strange. I heard a different song here[1], but haven't checked the fact=20
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=20
>might want for an embedded system: We have a stress test running for a
few=20
>weeks now simulating power-failures during writes to files on jffs2,
and mtd=20
>has some occasional hick-ups. Those hick-ups seem to be far less
serious than=20
>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=20
>write-error on the mtd device, preceded by an error message from the=20
>mtd-driver (and jffs2, but the problem seems to come from mtd). The
error=20
>message is like "MTD do_write_buffer(): software timeout", which
normally=20

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,=20
>but I don't think that is the case, since those problems began
appearing=20
>quite early and went away all by them selves. Flash doesn't magically
"fix"=20
itself over time, does it?
>Maybe it's a problem in the AMD flash driver (our device is a Spansion=20
Mirror-bit S29GL256M11)

Regards,
--=20
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 =3D map->fldrv_priv;
 	unsigned long timeo =3D 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 =3D ( HZ / 1000 ) + 1;
+#endif
 	int ret =3D 0;
 	map_word oldd;
 	int retry_cnt =3D 0;
@@ -987,8 +994,10 @@
 				adr, map_bankwidth(map),
 				chip->word_write_time);
=20
+#ifdef WANT_SHORT_WTIMEOUT
 	/* See comment above for timeout value. */
 	timeo =3D jiffies + uWriteTimeout;=20
+#endif
 	for (;;) {
 		if (chip->state !=3D FL_WRITING) {
 			/* Someone's suspended the write. Sleep */
@@ -1189,8 +1198,15 @@
 {
 	struct cfi_private *cfi =3D map->fldrv_priv;
 	unsigned long timeo =3D 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 =3D ( HZ / 1000 ) + 1;
+#endif
 	int ret =3D -EIO;
 	unsigned long cmd_adr;
 	int z, words;
@@ -1248,7 +1264,9 @@
 				adr, map_bankwidth(map),
 				chip->word_write_time);
=20
+#ifdef WANT_SHORT_WTIMEOUT
 	timeo =3D jiffies + uWriteTimeout;=20
+#endif
 	=09
 	for (;;) {
 		if (chip->state !=3D FL_WRITING) {