jffs2_scan_eraseblock() - errors

jffs2_scan_eraseblock() - errors

[Curtis, Allen]

While testing power-fail operation of JFFS2, I can consistently produce this
error which occurs when the partition is mounted.

jffs2_scan_eraseblock() - Node at 0xXXXXXX {0x1985, 0xe002, 0x1985c002) has
invalid CRC)

I do not remember if the error is always CRC related and the Node location
changes but the hex values displayed within the parens is consistent.

Has anyone seen this before? Some concerns are:
1. Once the error occurs, it never gets fixed.
2. There does not appear to be a utility to fix errors.

We are using MVista 2.1, which is 2.4.17. I was able to produce this error
with only 13 power-cycles.

Any help would be appreciated!
TIA

Re: jffs2_scan_eraseblock() - errors

[David Woodhouse]

Allen.Curtis@Thales-IFS.com said:
> While testing power-fail operation of JFFS2, I can consistently
> produce this error which occurs when the partition is mounted.

> jffs2_scan_eraseblock() - Node at 0xXXXXXX {0x1985, 0xe002,
> 0x1985c002) has invalid CRC)

> I do not remember if the error is always CRC related and the Node
> location changes but the hex values displayed within the parens is
> consistent.

> Has anyone seen this before? Some concerns are: 1. Once the error
> occurs, it never gets fixed. 2. There does not appear to be a utility
> to fix errors.

> We are using MVista 2.1, which is 2.4.17. I was able to produce this
> error with only 13 power-cycles. 

It's harmless. We were in the middle of writing that node when we lost
power, and hadn't finished writing the payload -- hence the CRC fails.
That's sort of what the CRC is there for. No data were lost -- either we
were garbage-collecting and the original copy of the data will still be on
the flash, or it was a write of new data which never made it to flash
because the write() call never returned -- just as if you pulled the plug a
moment sooner. 

It's actually possible to avoid the cosmetic annoyance by marking the node 
as obsolete, so we don't check the CRC and hence don't bitch about it 
failing. Older versions of JFFS2 did that, as does the current version in 
2.4.19-rc3. But it's harmless and expected behaviour.


--
dwmw2

Re: jffs2_scan_eraseblock() - errors

[Jörn Engel]

On Tue, 30 July 2002 23:21:51 +0100, David Woodhouse wrote:
> It's actually possible to avoid the cosmetic annoyance by marking the node 
> as obsolete, so we don't check the CRC and hence don't bitch about it 
> failing. Older versions of JFFS2 did that, as does the current version in 
> 2.4.19-rc3. But it's harmless and expected behaviour.

How exactly is this done? On the next mount after the failed write? By
toggling bits in the status word of the node header?

If so, this will not work with any of the shiny STMicro chips with
hardware ECC, so I would have to tackle that one too, once we merge.

Jörn

-- 
Jörn Engel
mailto: joern@wohnheim.fh-wedel.de
http://wohnheim.fh-wedel.de/~joern
Phone: +49 179 6704074

Re: jffs2_scan_eraseblock() - errors

[David Woodhouse]

joern@wohnheim.fh-wedel.de said:
>  How exactly is this done? On the next mount after the failed write?
> By toggling bits in the status word of the node header?

By marking it obsolete. It's an optimisation.

> If so, this will not work with any of the shiny STMicro chips with
> hardware ECC, so I would have to tackle that one too, once we merge. 

Doesn't matter. Our other plans for deferring CRC checking will avoid the 
harmless complaint.


--
dwmw2

Re: jffs2_scan_eraseblock() - errors

[Jörn Engel]

On Wed, 31 July 2002 12:45:52 +0100, David Woodhouse wrote:
> joern@wohnheim.fh-wedel.de said:
> >  How exactly is this done? On the next mount after the failed write?
> > By toggling bits in the status word of the node header?
> 
> By marking it obsolete. It's an optimisation.

And this marking as obsolete is done how? Does is involve writes to
the flash node, after it has already been written?

Sorry for me being clueless.

> > If so, this will not work with any of the shiny STMicro chips with
> > hardware ECC, so I would have to tackle that one too, once we merge. 
> 
> Doesn't matter. Our other plans for deferring CRC checking will avoid the 
> harmless complaint.

Ok, I can live with that.

Jörn

-- 
When in doubt, use brute force.
-- Ken Thompson

Re: jffs2_scan_eraseblock() - errors

[David Woodhouse]

joern@wohnheim.fh-wedel.de said:
>  And this marking as obsolete is done how? Does is involve writes to
> the flash node, after it has already been written?

> Sorry for me being clueless. 

Yep. There's a bit in the node type field which we clear to mark the node 
obsolete. And I've been very strict about making sure it's an optimisation 
_only_, and we never actually rely on being able do to it.

Deletion of directory entries, for example, could perhaps have been done 
just by marking the original as obsolete, but instead we do it by writing a 
new dirent with the same name and inode #0. 

--
dwmw2

Re: jffs2_scan_eraseblock() - errors

[Jörn Engel]

On Wed, 31 July 2002 12:59:09 +0100, David Woodhouse wrote:
> Yep. There's a bit in the node type field which we clear to mark the node 
> obsolete. And I've been very strict about making sure it's an optimisation 
> _only_, and we never actually rely on being able do to it.

Ok, then the stuff should be caught by the command set. But some tests
don't hurt either.
Very wise of you, btw.

Jörn

-- 
Good warriors cause others to come to them and do not go to others.
-- Sun Tzu

Re: jffs2_scan_eraseblock() - errors

[David Woodhouse]

joern@wohnheim.fh-wedel.de said:
>  Ok, then the stuff should be caught by the command set. But some
> tests don't hurt either.

Should be caught by jffs2_can_mark_obsolete() which checks the device type.

--
dwmw2

Re: jffs2_scan_eraseblock() - errors

[Jörn Engel]

On Wed, 31 July 2002 13:17:46 +0100, David Woodhouse wrote:
> Should be caught by jffs2_can_mark_obsolete() which checks the device type.

True. Ok, never mind.

Jörn

-- 
Invincibility is in oneself, vulnerability is in the opponent.
-- Sun Tzu

Problems with full FS

[Joakim Tjernlund]

Hi all

We have run into a problem with JFFS2(stable branch) lately. I don't have much detalis 
rigth now since I am on vacation(start to work on Monday). We have this directory
which contains a lot of log files and the FS is full.

When I cd to that dir and do a ls, it hangs in getdents64(0x3, 0x10024c30, 0x1000) forever(not 
always but 50% of the time) .
But if do a ls with the absolute path instead(that is, ls /var/log/lumentis) it works just fine.

Any ideas?

         Jocke

Oops when unlinking stale file

[Joakim Tjernlund]

When unlinking(in the stable branch) a stale file I got this:

JFFS2: Total scan time: 20.19 sec
Eep. Child "lumentis~" (ino #242) of dir ino #11 doesn't exist!
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 52k init 4k openfirmware

.....


jffs2_read_inode() on nonexistent ino 242
Oops: kernel access of bad area, sig: 11
NIP: C007FB54 XER: E000997F LR: C007FA98 SP: C516DDD0 REGS: c516dd20 TRAP: 0300
Using defaults from ksymoops -t elf32-little -a unknown
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c516c000[211] 'unlink' Last syscall: 10
last math 00000000 last altivec 00000000
GPR00: 00000000 C516DDD0 C516C000 00009032 00001032 0000000C C516DCF4 00000000
GPR08: C7DFA000 C5197DD0 C7C5D000 00000000 03E40000 100206E0 00000000 100AEED0
GPR16: 100BA9D0 10010000 10010000 00000000 00009032 0516DE80 00000000 C0002838
GPR24: C0002560 00000000 C7F3B2A0 C52E2BA0 C7A96070 C7A96180 C5197EE0 C7C5D290
Call backtrace:
C007FA98 C007FBC0 C0040FE8 C004113C C0002670 100004F4 0FED9DBC
00000000
Warning (Oops_read): Code line not seen, dumping what data is available

>>???; c007fb54 <jffs2_do_unlink+2e0/338>   <=====
Trace; c007fa98 <jffs2_do_unlink+224/338>
Trace; c007fbc0 <jffs2_unlink+14/24>
Trace; c0040fe8 <vfs_unlink+17c/1e8>
Trace; c004113c <sys_unlink+e8/194>
Trace; c0002670 <ret_from_syscall_2+0/44>
Trace; 100004f4 Before first symbol
Trace; 0fed9dbc Before first symbol
Trace; 00000000 Before first symbol