No subject

seems to hang the system in a live lock.

Situation:
=A0* immediately after boot an executable is started which calls mlockall()
   to commit all pages into RAM (this is a real time application)
=A0* the executable is read from a JFFS2 file system on NOR flash
=A0* mlockall() never terminates
=A0* console output is 'Data CRC f7e8ddd1 !=3D calculated CRC 47cee9c9
   for node at 00edc5cc' in an endless loop

My investigations are so far:
=A0* during boot some log output is written into a log file on the JFFS2
   that manipulates the file system --> no read only mount possible
=A0* the system is switched off at arbitrary times without clean unmount
   --> this clearly may leave behind blocks with data CRC errors
=A0* due to some reorganization (garbage collector?) my executable file
   data is moved across the flash
=A0* if such a move takes place exactly during power off two data frags
   carrying a portion of my executable file data are left behind, one "old"
   and correct frag and one "new" and incomplete frag with CRC error
=A0* during next boot mlockall() tries to read in all pages from the
   executable and fails on this point of CRC error

My questions:
=A0* is this a known behavior?
=A0* why is the fragment which has the CRC error relevant although
   the old and correct fragment is still in place?
=A0* are there relevant fixes in newer kernel versions which I should
   use? (I cannot update the kernel, but I may apply a patch)

Thanks a lot in advance!
Thommy