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

[Wolfgang Denk <wd@denx.de>]

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_