[ECOS] Getting segmentation fault while unmounting JFFS2 file system .

[ECOS] Getting segmentation fault while unmounting JFFS2 file system .

[Amitesh Singh]

Hi All
I am facing problem while umounting JFFS2 FS.
I am successfully able to mount JFFS2 system on CRAMFS root file
system but not able to umount it. It shows Seg.fault when i umount
this File system.
# umount /mnt
umount: Cannot open /etc/mtab
Unable to handle kernel NULL pointer dereference at virtual address 00000000
.
..
..
I am using CFI Flash device in physical memory map .
<*> CFI Flash device in physical memory map
       │ │
 │ │         (0x50000000) Physical start address of flash mapping
                     │ │
 │ │         (0x01000000) Physical length of flash mapping

 Earlier,i was facing same problem while mounting any MTD block then i
used the physical mapped flash map instead of the ixp_4xx map .
Now,I only able to mount but failed to unmount MTD device :P
Please help me out !

Thanks
Amitesh
http://www.amitesh.info





# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "RedBoot"
mtd1: 002a0000 00020000 "cramfs"
mtd2: 00ce0000 00020000 "unallocated"
mtd3: 00001000 00020000 "RedBoot config"
mtd4: 00020000 00020000 "FIS directory"
# modprobe jffs2
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
JFFS2: default compression mode: priority
# mount -t jffs2 /dev/mtdblock2 /mnt
mount: /etc/mtab: Read-only file system
# cd /mnt
# ls
System.map-2.6.11-1.1369_FC4  grub
config-2.6.11-1.1369_FC4      initrd-2.6.11-1.1369_FC4.img
gogole                        vmlinuz-2.6.11-1.1369_FC4
# cd ..
# umount /mnt
umount: Cannot open /etc/mtab
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c1a60000
[00000000] *pgd=01eef031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1]
Modules linked in: jffs2 zlib_deflate ixp400_eth ixp400
CPU: 0
PC is at __down_write+0xa0/0xd8
LR is at jffs2_flush_wbuf_pad+0x1c/0x3c [jffs2]
pc : [<c01aa5d4>]    lr : [<bf0c1c34>]    Tainted: P
sp : c1e79e64  ip : c1e79e8c  fp : c1e79e88
r10: 401a4000  r9 : c1e78000  r8 : c0023c64
r7 : 00000016  r6 : bf0ce698  r5 : c1a5b11c  r4 : c1c1e800
r3 : c1a5b120  r2 : 00000000  r1 : c1e79e64  r0 : c1a5b11c
Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  Segment user
Control: 39FF  Table: 01A60000  DAC: 00000015
Process umount (pid: 47, stack limit = 0xc1e78194)
Stack: (0xc1e79e64 to 0xc1e7a000)
9e60:          c1a5b120 00000000 c1c1e800 00000002 c1a5b000 c1a5b11c c1e79ea0
9e80: c1e79e8c bf0c1c34 c01aa540 c1a5b030 c18f45dc c1e79eb4 c1e79ea4 bf0bfa30
9ea0: bf0c1c24 c1a5b200 c1e79ec8 c1e79eb8 c0078900 bf0bfa00 c1a5b200 c1e79ee4
9ec0: c1e79ecc c007e288 c0078860 c1a5b000 bf0ce6e8 bea66e0c c1e79ef8 c1e79ee8
9ee0: bf0bffb4 c007e24c c1a5b200 c1e79f10 c1e79efc c007e1a4 bf0bffac c0295ae0
9f00: c1a5b200 c1e79f28 c1e79f14 c009452c c007e158 c1e79f40 00000000 c1e79f3c
9f20: c1e79f2c c0085118 c009450c 00000000 c1e79f94 c1e79f40 c0094b4c c00850dc
9f40: c18f45dc c0295ae0 c00ce91c 00000001 01f00002 00000001 00000001 00000000
9f60: bea66e0c c01db01c 00000002 0000b650 401a4000 c1e79f9c c1e79f84 c002a9c8
9f80: 00000000 00000000 c1e79fa4 c1e79f98 c0094b68 c0094ab8 00000000 c1e79fa8
9fa0: c0023ae0 c0094b60 00000000 c002ab4c bea66e0c 00000032 00000000 00044b10
9fc0: 00000000 00000000 bea66e0c bea66e0c 00000002 0000b650 401a4000 0003d820
9fe0: 40158460 bea66df4 0002a4ac 40158464 60000010 bea66e0c 01e79ff8 01e79ffc
Backtrace:
[<c01aa534>] (__down_write+0x0/0xd8) from [<bf0c1c34>]
(jffs2_flush_wbuf_pad+0x1c/0x3c [jffs2])
 r5 = C1A5B11C  r4 = C1A5B000
[<bf0c1c18>] (jffs2_flush_wbuf_pad+0x0/0x3c [jffs2]) from [<bf0bfa30>]
(jffs2_sync_fs+0x3c/0x68 [jffs2])
 r5 = C18F45DC  r4 = C1A5B030
[<bf0bf9f4>] (jffs2_sync_fs+0x0/0x68 [jffs2]) from [<c0078900>]
(fsync_super+0xac/0xcc)
 r4 = C1A5B200
[<c0078854>] (fsync_super+0x0/0xcc) from [<c007e288>]
(generic_shutdown_super+0x48/0x148)
 r4 = C1A5B200
[<c007e240>] (generic_shutdown_super+0x0/0x148) from [<bf0bffb4>]
(jffs2_kill_sb+0x14/0x28 [jffs2])
 r6 = BEA66E0C  r5 = BF0CE6E8  r4 = C1A5B000
[<bf0bffa0>] (jffs2_kill_sb+0x0/0x28 [jffs2]) from [<c007e1a4>]
(deactivate_super+0x58/0x6c)
 r4 = C1A5B200
[<c007e14c>] (deactivate_super+0x0/0x6c) from [<c009452c>] (__mntput+0x2c/0x30)
 r5 = C1A5B200  r4 = C0295AE0
[<c0094500>] (__mntput+0x0/0x30) from [<c0085118>]
(path_release_on_umount+0x48/0x4c)
 r5 = 00000000  r4 = C1E79F40
[<c00850d0>] (path_release_on_umount+0x0/0x4c) from [<c0094b4c>]
(sys_umount+0xa0/0xa8)
 r4 = 00000000
[<c0094aac>] (sys_umount+0x0/0xa8) from [<c0094b68>] (sys_oldumount+0x14/0x18)
 r5 = 00000000  r4 = 00000000
[<c0094b54>] (sys_oldumount+0x0/0x18) from [<c0023ae0>]
(ret_fast_syscall+0x0/0x2c)
Code: e5932004 e5831004 e50b3024 e50b2020 (e5821000)
 Segmentation fault
# reboot&
[1] 48

The system is going down NOW !!
# ps -e
 PID  Uid     VmSize Stat Command
  1 root        320 S   /bin/init 32M@0x00000000
  2 root            SWN [ksoftirqd/0]
  3 root            SW< [events/0]
  4 root            SW< [khelper]
  5 root            SW< [kthread]
  6 root            SW< [kblockd/0]
  7 root            SW  [pdflush]
  8 root            SW  [pdflush]
 10 root            SW< [aio/0]
  9 root            SW  [kswapd0]
 11 root            SW  [mtdblockd]
 12 root            SW  [ftld]
 23 root            SW< [ixp400_eth/0]
 32 root       1072 S   /bin/sh
 45 root            SWN [jffs2_gcd_mtd2]
 48 root        528 D   reboot
 49 root        600 R   ps -e
#

Re: [ECOS] Getting segmentation fault while unmounting JFFS2 file system .

[Gary Thomas]

Amitesh Singh wrote:
> Hi All
> I am facing problem while umounting JFFS2 FS.
> I am successfully able to mount JFFS2 system on CRAMFS root file
> system but not able to umount it. It shows Seg.fault when i umount
> this File system.
> # umount /mnt
> umount: Cannot open /etc/mtab
> Unable to handle kernel NULL pointer dereference at virtual address 
> 00000000
> .
> ..
> ..
> I am using CFI Flash device in physical memory map .
> <*> CFI Flash device in physical memory map
>       │ │
> │ │         (0x50000000) Physical start address of flash mapping
>                     │ │
> │ │         (0x01000000) Physical length of flash mapping
> 
> Earlier,i was facing same problem while mounting any MTD block then i
> used the physical mapped flash map instead of the ixp_4xx map .
> Now,I only able to mount but failed to unmount MTD device :P
> Please help me out !

This is purely a JFFS2 problem and has nothing to do with RedBoot/eCos
- take it up with the folks that support JFFS2.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] JFFS2 Access and interrupts

[Gernot Zankl]

Hi all,

while writing a file in a jffs2 filesystem (by means of open, write,
close)
my application seems to hang in function write(). 
After guarding the write access with
HA_DISABLE_INTERRUPTS/HAL_RESTORES_INTERRUPTS 
the write accesses worked properly.

After a short inspection of flash.c (in packages/io/flash/current/src)
it seems that in my port these guards are already present,
placed around the "__anonymizer"-ed flash access functions.

Is there a general rule, how to handle mutual IRQs and flash access ?
Do I miss something ?
Is there a configuration option, I've forgotten to enable ?

Kind regards,
Gernot Zankl

Btw: PowerPC MPC5200B and external flash Spansion S29GL064M


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] JFFS2 Access and interrupts

[Gary Thomas]

Gernot Zankl wrote:
> Hi all,
> 
> while writing a file in a jffs2 filesystem (by means of open, write,
> close)
> my application seems to hang in function write(). 
> After guarding the write access with
> HA_DISABLE_INTERRUPTS/HAL_RESTORES_INTERRUPTS 
> the write accesses worked properly.
> 
> After a short inspection of flash.c (in packages/io/flash/current/src)
> it seems that in my port these guards are already present,
> placed around the "__anonymizer"-ed flash access functions.
> 
> Is there a general rule, how to handle mutual IRQs and flash access ?
> Do I miss something ?
> Is there a configuration option, I've forgotten to enable ?

There aren't any configuration options for this - it's assumed to work.

Can you please explain in more detail exactly what you've done to get
things to work?  Given that the generic functions (e.g. flash_program)
already disable interrupts, I'm a bit confused.

> 
> Kind regards,
> Gernot Zankl
> 
> Btw: PowerPC MPC5200B and external flash Spansion S29GL064M

Given that the eCos port for the MPC5200 is not public (you got it
from Analogue & Micro), it makes sense to ask these questions of
A&M, not the general list.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] JFFS2 Access and interrupts

[Bart Veer]

>>>>> "Gernot" == Gernot Zankl <zankl@decomsys.com> writes:

    Gernot> while writing a file in a jffs2 filesystem (by means of
    Gernot> open, write, close) my application seems to hang in
    Gernot> function write(). After guarding the write access with
    Gernot> HA_DISABLE_INTERRUPTS/HAL_RESTORES_INTERRUPTS the write
    Gernot> accesses worked properly.

    Gernot> After a short inspection of flash.c (in
    Gernot> packages/io/flash/current/src) it seems that in my port
    Gernot> these guards are already present, placed around the
    Gernot> "__anonymizer"-ed flash access functions.

    Gernot> Is there a general rule, how to handle mutual IRQs and
    Gernot> flash access ? Do I miss something ? Is there a
    Gernot> configuration option, I've forgotten to enable ?

A basic rule of working with flash is that if any code is erasing or
programming part of the flash then no other code can access it. Some
flash chips relax that restriction somewhat by providing several
banks, but at best that is only a partial solution. Flash accesses can
come from a variety of sources.

  1) I do not know too much about jffs2 internals (I leave that to
     others) but I suspect that there is enough locking within jffs2
     to prevent two threads from accessing the flash h/w concurrently
     while performing file I/O.

  2) If your board uses a RedBoot residing in flash, as opposed to a
     ROMRAM version, then the application may switch to RedBoot and
     hence execute from flash for a variety of reasons. The thread
     performing file I/O may get preempted and some other thread then
     calls printf(), diag_printf(), or anything similar which involves
     I/O via the virtual vector mechanism. Or the other thread may hit
     a breakpoint, activating the gdb stubs. Or there may be a virtual
     vector access to the fis or fconfig data. Or the code may throw
     an exception.

  3) some other thread may access the flash for some other reason,
     either via the flash API or directly. Especially if the
     application itself resides in flash.

The anoncvs trunk still uses the V1 API. Basically this does not
address any locking issues at all. Note that the default versions of
the HAL_FLASH_CACHES_...() macros only affect the cache, not
interrupts, so there is nothing to stop the current thread from being
interrupted or preempted. (Actually, manipulating the caches without
considering interrupts is itself rather dodgy). Possibly the platform
HAL for your port defines more advanced macros. There are some
scenarios where you may just be able to get away with this - a ROMRAM
RedBoot, absolutely nothing else using the flash - but it is not a
robust solution.

Anoncvs also has a V2 flash development branch which addresses some of
the problems. In particular it adds mutex locking for accessing flash
devices, so if the only other flash accesses happen via the V2 flash
API then you'll be ok. Again a ROMRAM RedBoot would be a very good
idea.

eCosCentric has done further work on the V2 flash drivers which has
not yet gone into anoncvs. This adds optional interrupt
disabling/reenabling where it is needed, right inside the drivers
themselves, together with support for program burst and for erase
suspend mode to limit the effect on real-time behaviour. There are
various configuration options so you can fine tune the drivers'
behaviour, basically trading off performance for interrupt response
times. With these drivers the application no longer needs to worry
about IRQs during flash accesses on non-SMP systems, it is all done
automatically.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] JFFS2 Access and interrupts

[Andrew Lunn]

>   1) I do not know too much about jffs2 internals (I leave that to
>      others) but I suspect that there is enough locking within jffs2
>      to prevent two threads from accessing the flash h/w concurrently
>      while performing file I/O.

I don't know JFFS2 too well either, but im sure with a single
filesystem, it will serialise access to the flash. When there are
multiple filesystems mounted from the same flash i've no idea if
simultanious access to different filesystems are serialised. It could
be than in the Linux world the MTD layer sorts this out?

   Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] JFFS2 Access and interrupts

[Gernot Zankl]

Hi all !

> A basic rule of working with flash is that if any code is erasing or
> programming part of the flash then no other code can access it. Some
> flash chips relax that restriction somewhat by providing several
> banks, but at best that is only a partial solution. Flash accesses can
> come from a variety of sources.

I'm using ROMRAM versin of redboot and the applications runs in RAM,
too.
Are there any calls to the ROM version of the redboot during the
execution
of a "normal" application, which would cause reading access to the flash
?

>   3) some other thread may access the flash for some other reason,
>      either via the flash API or directly. Especially if the
>      application itself resides in flash.

The application is (currently) loaded from the tftp server and is
executed in
RAM. There exists just one jffs2 partition and it's the only one
mounted.

> Anoncvs also has a V2 flash development branch which addresses some of
> the problems. In particular it adds mutex locking for accessing flash
> devices, so if the only other flash accesses happen via the V2 flash
> API then you'll be ok. Again a ROMRAM RedBoot would be a very good
> idea.

I want to give the v2 version a try. As far as i've seen, there exists a
flas_v2 branch in the CVS.
Are the modules devs/flash, io/flash and fs/jffs2 the only ones, I've to
upgrade ?

I built a test application (heavily based on one of the jffs2 tests),
where
cyclically files (with size f) are allocated, filed with rand()-values, 
crc-checked and finally erased. 
Starting with a fresh partition (all filled with 0xff) of size S, 
it seems that after a number of iterations i, jffs2 produces a lot of
warnings
(see below), where always approx. i * f = S.
The test continues, but most of the time hangs some iterations later.

><INFO> Iteration 0000058: passed=0000058, failed=0000000
><5>JFFS2 notice:  read_unknown: node header CRC failed at %#08x. But it
must have been OK earlier.
><4>Node totlen on flash (0xffffffff) != totlen from node ref
(0x00001034)
><4>JFFS2 warning:  jffs2_do_read_inode_internal: no data nodes found
for ino #60
>jffs2_read_inode() failed
>jffs2_iget() failed for ino #60
><ERROR>: open() returned -1 I/O error
><ERROR>: read() returned -1 Bad file handle
>File <test0000058> is corrupt<ERROR>: read() returned -1 Bad file
handle
><4>JFFS2 warning:  jffs2_get_inode_nodes: no valid nodes for ino #60
><4>JFFS2 warning:  jffs2_do_read_inode_internal: no data nodes found
for ino #60
>jffs2_read_inode() failed
>jffs2_iget() failed for ino #60
><ERROR>: unlink() returned -1 I/O error
><4>Node CRC ffffffff != calculated CRC f09e7845 for node at 0003f610
><ERROR>: read() returned 3
>File <test0000059> is corrupt<INFO> Iteration 0000059: passed=0000058,
failed=0000007
><5>JFFS2 notice:  read_unknown: node header CRC failed at %#08x. But it
must have been OK earlier.
><4>Node totlen on flash (0xffffffff) != totlen from node ref
(0x000009f0)
>File <test0000059> is corrupt<4>Node totlen on flash (0xffffffff) !=
totlen from node ref (0x00000034)
><INFO> Iteration 0000060: passed=0000058, failed=0000008

Inbetween the aplication also produces:

><INFO> Iteration 0000207: passed=0000201, failed=0000024
><4>Node totlen on flash (0xffffffff) != totlen from node ref
(0x00000034)
><4>Node totlen on flash (0xffffffff) != totlen from node ref
(0x00000034)
><4>Node totlen on flash (0xffffffff) != totlen from node ref
(0x00000034)
><4>Node totlen on flash (0xffffffff) != totlen from node ref
(0x00000034)
><4>Node totlen on flash (0xffffffff) != totlen from node ref
(0x00000034)
><4>Node totlen on flash (0xffffffff) != totlen from node ref
(0x00000034)
><4>Node totlen on flash (0xffffffff) != totlen from node ref
(0x00000034)
><4>Node totlen on flash (0xffffffff) != totlen from node ref
(0x00000034)
><INFO> Iteration 0000208: passed=0000202, failed=0000024

Regards,
Gernot Zankl


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] JFFS2 Access and interrupts

[Andrew Lunn]

On Fri, Sep 08, 2006 at 11:59:48AM +0200, Gernot Zankl wrote:
> Hi all !
> 
> > A basic rule of working with flash is that if any code is erasing or
> > programming part of the flash then no other code can access it. Some
> > flash chips relax that restriction somewhat by providing several
> > banks, but at best that is only a partial solution. Flash accesses can
> > come from a variety of sources.
> 
> I'm using ROMRAM versin of redboot and the applications runs in RAM,
> too.
> Are there any calls to the ROM version of the redboot during the
> execution
> of a "normal" application, which would cause reading access to the flash
> ?

There shoudn't be. But it is worth checking the interrupt vectors and
VV are pointing to RAM addresses not ROM addresses. It could be the
ROMRAM startup code is not quite right and its still using ROM
addresses. Such a system might run, but experiance problems with
interrupts during flash handling.

> I want to give the v2 version a try. As far as i've seen, there exists a
> flas_v2 branch in the CVS.
> Are the modules devs/flash, io/flash and fs/jffs2 the only ones, I've to
> upgrade ?

If your problem is in Redboot, you might also need the redboot
directory from the branch.

> I built a test application (heavily based on one of the jffs2 tests),
> where
> cyclically files (with size f) are allocated, filed with rand()-values, 
> crc-checked and finally erased. 
> Starting with a fresh partition (all filled with 0xff) of size S, 
> it seems that after a number of iterations i, jffs2 produces a lot of
> warnings
> (see below), where always approx. i * f = S.
> The test continues, but most of the time hangs some iterations later.

It might be interesting to run this on the synthetic target. It has no
interrupts as such, so you can test if this is a jffs2 problem, not a
flash problem.

           Andrew            

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] JFFS2 Access and interrupts

[Gernot Zankl]

Hi all !

Thanks for your answers.
FYI I finally found the/our bug, causing the application to 
corrupt the jffs2. We just used the wrong block size in
the configuration of the underlying flash driver, causing to
erase too much flash memory (and destroying still active inodes).

Regards,
Gernot Zankl


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] JFFS2 Access and interrupts

[Gary Thomas]

Gernot Zankl wrote:
> Hi all !
> 
> Thanks for your answers.
> FYI I finally found the/our bug, causing the application to 
> corrupt the jffs2. We just used the wrong block size in
> the configuration of the underlying flash driver, causing to
> erase too much flash memory (and destroying still active inodes).

FAOD - it had *nothing* to do with interrupts during FLASH operations?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] JFFS2 Access and interrupts

[Gernot Zankl]

 
Gary Thomas wrote:
> Gernot Zankl wrote:
> > Hi all !
> > 
> > Thanks for your answers.
> > FYI I finally found the/our bug, causing the application to 
> > corrupt the jffs2. We just used the wrong block size in
> > the configuration of the underlying flash driver, causing to
> > erase too much flash memory (and destroying still active inodes).
> 
> FAOD - it had *nothing* to do with interrupts during FLASH operations?

At least not in "our" version of the flash driver (v1) which has been 
provided and modified by Analogue&Micro, where all calls to the 
critical functions are guarded by the HAL_DISABLE_INTERRUPTS and
HAL_RESTORES_INTERRUPTS macros.

Regards,
Gernot Zankl

Btw. what does "FAOD" mean, "Fatty acid oxidation disorder" ?



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] JFFS2 Access and interrupts

[Gary Thomas]

Gernot Zankl wrote:
>  
> Gary Thomas wrote:
>> Gernot Zankl wrote:
>>> Hi all !
>>>
>>> Thanks for your answers.
>>> FYI I finally found the/our bug, causing the application to 
>>> corrupt the jffs2. We just used the wrong block size in
>>> the configuration of the underlying flash driver, causing to
>>> erase too much flash memory (and destroying still active inodes).
>> FAOD - it had *nothing* to do with interrupts during FLASH operations?
> 
> At least not in "our" version of the flash driver (v1) which has been 
> provided and modified by Analogue&Micro, where all calls to the 
> critical functions are guarded by the HAL_DISABLE_INTERRUPTS and
> HAL_RESTORES_INTERRUPTS macros.

Good, thanks.

> 
> Btw. what does "FAOD" mean, "Fatty acid oxidation disorder" ?
> 

For Avoidance Of Doubt (it's a common British saying which I also
had to have explained to me many years ago...)


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] JFFS2 Access and interrupts

[Bart Veer]

>>>>> "Gernot" == Gernot Zankl <zankl@decomsys.com> writes:

    >> > FYI I finally found the/our bug, causing the application to
    >> > corrupt the jffs2. We just used the wrong block size in
    >> > the configuration of the underlying flash driver, causing to
    >> > erase too much flash memory (and destroying still active inodes).
    >> 
    >> FAOD - it had *nothing* to do with interrupts during FLASH operations?

    Gernot> At least not in "our" version of the flash driver (v1)
    Gernot> which has been provided and modified by Analogue&Micro,
    Gernot> where all calls to the critical functions are guarded by
    Gernot> the HAL_DISABLE_INTERRUPTS and HAL_RESTORES_INTERRUPTS
    Gernot> macros.

Of course that approach gives you an interrupt latency of somewhere
from several 100 milliseconds up to 5 seconds, depending on the exact
flash hardware and the environmental conditions. That is the time
needed to erase a whole flash sector. So any time you perform jffs2
file I/O your application may become completely unresponsive to all
external events for a number of seconds. It depends on the application
whether or not such behaviour is acceptable.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss