Though this posting is from 2009, I just ran into the same problem recently.
We use a patched JFFS2 file system in eCos on a Freescale MPC5668 processor.
The umount-function there has not released the flash i/o handles, resulting
in exactly the described problem: After CYGNUM_IO_FLASH_BLOCK_DEVICES
remounts, mount failed because no flash handles were available any longer.
I now added the call to flashiodev_set_config to the umount function as
follows:
if (--n_fs_mounted == 0) {
jffs2_destroy_slab_caches();
jffs2_compressors_exit();
// Release the flash device i/o handler
flashiodev_set_config(
jffs2_sb->s_dev,
CYG_IO_SET_CONFIG_CLOSE,
(void*) NULL,
0);
}
This results in the 'fs-test3.c' test case provided with eCos to run
smoothly, re-mounting lots of times.
I wonder however:
1) The documentation "Using FLASH I/O devices" [1] speaks of the function
'cyg_io_setconfig' instead of 'flashiodev_set_config'. I haven't found
anything regarding this function name in my eCos base package besides two
occurrences in a manual file. Does this function even exist inside the code?
2) The function 'flashiodev_set_config' is statically declared inside
'flashiodev.c'. I had to mess up the code a bit to get this function to be
known inside the jffs2-source file as well. Wouldn't it make more sense if
functions like this would be declared inside a header file which can easily
be included elsewhere?
Regards
- Daniel
[1] http://ecos.sourceware.org/docs-3.0/ref/ecos-flash-iodevice-usage.html
--
View this message in context:
http://sourceware-org.1504.n7.nabble.com/umount-leaks-dev-flash-device-slots-tp195700p250770.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
