JFFS2 Problem

JFFS2 Problem

[Snehaprabha]

I am having an issue with the JFFS2 file system, looks like the issue is with 
Garbage Collection. This is what I have done - 

I copy a file, and delete it for several times;  (You can think of a case 
where a configuration file is written again and again).

Depending on the space I had initially, it reaches a stage, where I cannot  
copy the file any more though 'df' shows enough available space for the file.

Is it an issue with GC ?

Any idea?


Sneha

Re: JFFS2 Problem

[David Woodhouse]

nsnehaprabha@tnint11.telogy.design.ti.com said:
>  I copy a file, and delete it for several times;  (You can think of a
> case  where a configuration file is written again and again).

> Depending on the space I had initially, it reaches a stage, where I
> cannot   copy the file any more though 'df' shows enough available
> space for the file. 

Until recently there was a bug where we wouldn't reclaim the space if you 
renamed one file over another. Could it be that? If not, it's not a known 
problem.

What version of the JFFS2 code are you using? Do you have a serial console? 
Can you set CONFIG_JFFS2_FS_DEBUG=1 and set the console loglevel to 9 so 
that all the resulting KERN_DEBUG messages are printed, then reproduce the 
problem while logging the output?


--
dwmw2

Re: JFFS2 Problem

[Snehaprabha]

Thanks for the response.
I am running 2.4.17 Kernel. I have a limitation on the flash size (AMD flash 
2MB with 64K erase block size). I am running our own bootloader which takes 
up 3 erase blocks. Then I have the linux kernel that takes around 12 erase 
blocks, leaving 17 erase blocks for the JFFS2 image. I have managed to fit in 
most of the required pieces for the file system, which makes it 17 blocks. 
Now the question is about the spare erase block required for GC.
I am confused with the #defines in fs/jffs2/nodelist.h

I have almost got it working with following values.

#define JFFS2_RESERVED_BLOCKS_BASE 1 /*3*/
#define JFFS2_RESERVED_BLOCKS_WRITE (JFFS2_RESERVED_BLOCKS_BASE + 1/*2*/)
#define JFFS2_RESERVED_BLOCKS_DELETION (JFFS2_RESERVED_BLOCKS_BASE /*+ 1*/) 
#define JFFS2_RESERVED_BLOCKS_GCTRIGGER (JFFS2_RESERVED_BLOCKS_BASE /*+ 3*/)
#define JFFS2_RESERVED_BLOCKS_GCBAD (JFFS2_RESERVED_BLOCKS_BASE + 1)
#define JFFS2_RESERVED_BLOCKS_GCMERGE (JFFS2_RESERVED_BLOCKS_BASE)

I want to know what are correct and reasonable values?

Thanks
Sneha



On Thursday 11 July 2002 03:05 am, David Woodhouse wrote:
> nsnehaprabha@tnint11.telogy.design.ti.com said:
> >  I copy a file, and delete it for several times;  (You can think of a
> > case  where a configuration file is written again and again).
> >
> > Depending on the space I had initially, it reaches a stage, where I
> > cannot   copy the file any more though 'df' shows enough available
> > space for the file.
>
> Until recently there was a bug where we wouldn't reclaim the space if you
> renamed one file over another. Could it be that? If not, it's not a known
> problem.
>
> What version of the JFFS2 code are you using? Do you have a serial console?
> Can you set CONFIG_JFFS2_FS_DEBUG=1 and set the console loglevel to 9 so
> that all the resulting KERN_DEBUG messages are printed, then reproduce the
> problem while logging the output?

Re: JFFS2 Problem

[Russ Dill]

On Thu, 2002-07-11 at 12:18, Snehaprabha wrote:
> Thanks for the response.
> I am running 2.4.17 Kernel. I have a limitation on the flash size (AMD flash 
> 2MB with 64K erase block size). I am running our own bootloader which takes 
> up 3 erase blocks. Then I have the linux kernel that takes around 12 erase 
> blocks, leaving 17 erase blocks for the JFFS2 image. I have managed to fit in 
> most of the required pieces for the file system, which makes it 17 blocks. 
> Now the question is about the spare erase block required for GC.
> I am confused with the #defines in fs/jffs2/nodelist.h

I don't know your requirements, but there are probably better ways of
doing whatever you are doing. On my 2M board, my flash layout looks like
this:

dev:    size   erasesize  name
mtd0: 00008000 00008000 "BLOB boot loader"
mtd1: 00008000 00004000 "NESA journaled config"
mtd2: 00010000 00010000 "NESA static config"
mtd3: 00060000 00020000 "NESA cramfs saveme"
mtd4: 00180000 00020000 "NESA cramfs root"

(note that 0x8000 is 32k, 0x10000 is 64k, etc)
768k is pretty big for a kernel, but if your need that many drivers,
that is the way it goes. A bootloader should be able to fit in one
block, by using bottom boot block flash, I can make even more efficient
use of the first block by subdividing it. I don't see where a 2M system
would need jffs2, my /proc/mounts looks like this:

/dev/root / cramfs rw 0 0
ramfs /etc ramfs rw 0 0
ramfs /var ramfs rw 0 0
ramfs /tmp ramfs rw 0 0
proc /proc proc rw 0 0

/etc is created by copying /init-etc from the cramfs partition at boot.
Any files that need to be saved across boots are tar.gz'd and saved to
the journalled config sectors by writing to that flash raw and including
a revision and crc.

I'm not saying that you should do it exactly this way, but hopefully it
will give you some ideas beyond what you are currently doing.

Re: JFFS2 problem

[Artem B. Bityutskiy]

Hello Amit,

Amit Kumar Sharma wrote:
> I am looking for JFFS2 stable version for kernel 2.4, Can u help me because
> I am facing strange problem. My device size is 187M and JFFS2 creating 2G
> file on my device. But when I checked same device partition on 2.6 kernel it
> also show file size 2G "it can not be possible because MTD partition is 187M
> " SO I run same test program on 2.6 kernel. it stops after creating 187M
> file size. SO I wonder may it is a problem of JFFS2 version I am using with
> mvl 2.4.20 kernel.

I'd suggest you to contact MV instead. MTD community is mostly not 
interested in 2.4, so you probably won't get any help here.

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.

JFFS2 problem

[Amit Kumar Sharma]

Hi 

I am looking for JFFS2 stable version for kernel 2.4, Can u help me because
I am facing strange problem. My device size is 187M and JFFS2 creating 2G
file on my device. But when I checked same device partition on 2.6 kernel it
also show file size 2G "it can not be possible because MTD partition is 187M
" SO I run same test program on 2.6 kernel. it stops after creating 187M
file size. SO I wonder may it is a problem of JFFS2 version I am using with
mvl 2.4.20 kernel.

Rgs
Amit

Re: jffs2 problem

[Hinko Kocevar]

Hinko Kocevar wrote:

> 
> I've spotted possible problem here - it seems that kernel overwrites 
> part of the rootfs at the begining - I have reserved 0xe0000 for kernel 
> partition, but I noticed that my newer kernels are larger than this. 
> Need to check this out...
> 

Yep, that was it. If my memory serves me well, I already had similar problems a 
while ago when I had to raise the kernel mtd partition from ~600k to 900k.

Where is this re-sizing gonna stop? ;)

Sorry for the noise.

-- 
..because under Linux "if something is possible in principle,
then it is already implemented or somebody is working on it".

					--LKI

Re: jffs2 problem

[Artem B. Bityuckiy]

Steven Scholz wrote:
>     echo 8 > /proc/sys/kernel/printk

Yep, or 'dmesg -n8'

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: jffs2 problem

[Hinko Kocevar]

Artem B. Bityuckiy wrote:
> Hinko Kocevar wrote:
> 
>> There you go. This is with JFFS2 debug set to 2 and MTD debug set to 3.
>> ...
>> NET: Registered protocol family 17
>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 
>> 0x234a instead
> 
> 
> Even though you enabled JFFS2 debugging,
> the debugging messages are not seen on your console.
> 
> Could you please dump the first N (say, 128) bytes at the offset 
> 0x00000000 of the JFFS2 partition (/dev/mtd2)? Does it contain 0x234a 
> (LE) as the first 16-bit word?
> 

Creating 3 MTD partitions on "Trizeps2 flash":
0x00000000-0x00060000 : "Bootloader"
mtd: Giving out device 0 to Bootloader
0x00060000-0x00140000 : "Kernel"
mtd: Giving out device 1 to Kernel
0x00140000-0x01000000 : "Filesystem"
mtd: Giving out device 2 to Filesystem


Core#0>md 0x140000
00140000 : 20031985 0000000c e41eb0b1 e0011985  ... ............
00140010 : 0000002b 7d266ee6 00000001 00000000  +....n&}........
00140020 : 00000002 424913b1 00000403 daeea20c  ......IB........
00140030 : 556683ff ff6e6962 e0021985 00000044  ..fUbin.....D...
00140040 : 98f7fb1d 00000002 00000001 000041ed  .............A..
00140050 : 006403e8 00000000 424913b1 424913b1  ..d.......IB..IB
00140060 : 424913b1 00000000 00000000 00000000  ..IB............
00140070 : 00000000 00000000 379225cb e0011985  .........%.7....
00140080 : 0000002b 7d266ee6 00000001 00000001  +....n&}........
00140090 : 00000003 4242dd58 00000403 855955ad  ....X.BB.....UY.
001400a0 : ee322817 ff766564 e0021985 00000044  .(2.dev.....D...
001400b0 : 98f7fb1d 00000003 00000001 000041ed  .............A..
001400c0 : 006403e8 00000000 4242dd58 4242dd58  ..d.....X.BBX.BB
001400d0 : 4242dd58 00000000 00000000 00000000  X.BB............
001400e0 : 00000000 00000000 c54033c0 e0011985  .........3@.....
001400f0 : 0000002b 7d266ee6 00000001 00000002  +....n&}........


I've spotted possible problem here - it seems that kernel overwrites part of 
the rootfs at the begining - I have reserved 0xe0000 for kernel partition, but 
I noticed that my newer kernels are larger than this. Need to check this out...

-- 
..because under Linux "if something is possible in principle,
then it is already implemented or somebody is working on it".

					--LKI

Re: jffs2 problem

[Steven Scholz]

Artem B. Bityuckiy wrote:

> Hinko Kocevar wrote:
> 
>> There you go. This is with JFFS2 debug set to 2 and MTD debug set to 3.
>> ...
>> NET: Registered protocol family 17
>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 
>> 0x234a instead
> 
> 
> Even though you enabled JFFS2 debugging,
> the debugging messages are not seen on your console.

Maybe

	echo 8 > /proc/sys/kernel/printk

???

--
Steven

Re: jffs2 problem

[Artem B. Bityuckiy]

Hinko Kocevar wrote:
> There you go. This is with JFFS2 debug set to 2 and MTD debug set to 3.
> ...
> NET: Registered protocol family 17
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 
> 0x234a instead

Even though you enabled JFFS2 debugging,
the debugging messages are not seen on your console.

Could you please dump the first N (say, 128) bytes at the offset 
0x00000000 of the JFFS2 partition (/dev/mtd2)? Does it contain 0x234a 
(LE) as the first 16-bit word?

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: jffs2 problem

[Hinko Kocevar]

Artem B. Bityuckiy wrote:
>> Flash is NOR Intel E28F128J3A150.
>>
>> I'm booting with NFS enabled kernel and rootfs over NFS, then erasing 
>> mtd partition that holds rootfs and then copying rootfs.jffs2 to mtd 
>> partition like this:
> 
> 
> Could you please enable JFFS2 debugging and post its output?
> 

There you go. This is with JFFS2 debug set to 2 and MTD debug set to 3.
...
NET: Registered protocol family 17
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0x234a 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004: 0x755a 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000008: 0x7404 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000000c: 0x2e9e 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x7084 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000014: 0x3922 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000018: 0x3d61 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000001c: 0x8bd7 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000020: 0x71ed 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000024: 0x0f2a 
instead
Further such events for this erase block will not be printed
Old JFFS2 bitmask found at 0x00005ae4
You cannot use older JFFS2 filesystems with newer kernels
Old JFFS2 bitmask found at 0x00006d1c
You cannot use older JFFS2 filesystems with newer kernels
JFFS2: Erase block at 0x00000000 is not formatted. It will be erased
SR.4 or SR.5 bits set in buffer write (status b0). Clearing.


I dont't understand why would JFFS2 complain about older fs and newer kernel if 
I'm using mkfs.jffs2 from July 2005 snapshot?!

-- 
..because under Linux "if something is possible in principle,
then it is already implemented or somebody is working on it".

					--LKI

Re: jffs2 problem

[Artem B. Bityuckiy]

> Flash is NOR Intel E28F128J3A150.
> 
> I'm booting with NFS enabled kernel and rootfs over NFS, then erasing 
> mtd partition that holds rootfs and then copying rootfs.jffs2 to mtd 
> partition like this:

Could you please enable JFFS2 debugging and post its output?

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: jffs2 problem

[Hinko Kocevar]

Artem B. Bityuckiy wrote:
> Hinko Kocevar wrote:
> 
>> Hi,
>>
>> I'm trying to use latest MTD CVS snapshot to create jffs2 image and 
>> boot my ARM target using that image as rootfs. Booting halts at:
> 
> 
> How did you check that your (probably correct) image was correctly 
> written to the flash? May be there are some driver-level problems ? What 
> kind of flash is that ?
> 

Flash is NOR Intel E28F128J3A150.

I'm booting with NFS enabled kernel and rootfs over NFS, then erasing mtd 
partition that holds rootfs and then copying rootfs.jffs2 to mtd partition like 
this:

$ flash_eraseall /dev/mtd2
$ cp /tmp/rootfs.jffs2 /dev/mtd2

I can mount jffs2 partition afterwards with:
$ mount -t jffs2 /dev/mtdblock2 /mnt/jffs2
$ ls /mnt/jffs2/
bin      etc      linuxrc  proc     staging  usr
dev      lib      mnt      sbin     tmp      var

regards,
hk
-- 
..because under Linux "if something is possible in principle,
then it is already implemented or somebody is working on it".

					--LKI

Re: jffs2 problem

[Artem B. Bityuckiy]

Hinko Kocevar wrote:
> Hi,
> 
> I'm trying to use latest MTD CVS snapshot to create jffs2 image and boot 
> my ARM target using that image as rootfs. Booting halts at:

How did you check that your (probably correct) image was correctly 
written to the flash? May be there are some driver-level problems ? What 
kind of flash is that ?

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

jffs2 problem

[Hinko Kocevar]

Hi,

I'm trying to use latest MTD CVS snapshot to create jffs2 image and boot my ARM 
target using that image as rootfs. Booting halts at:
...
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000018: 0xfe48 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000001c: 0xa2f9 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000020: 0x8db7 
instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000024: 0x9549 
instead
Further such events for this erase block will not be printed
Old JFFS2 bitmask found at 0x000073a0
You cannot use older JFFS2 filesystems with newer kernels
JFFS2: Erase block at 0x00000000 is not formatted. It will be erased
SR.4 or SR.5 bits set in buffer write (status b0). Clearing.

This is on 2.6.12.2. On 2.6.9 image is correctly mounted and booted. I belive 
that mkfs.jffs2 is one of the latest -
$ mkfs.jffs2 --version
mkfs.jffs2: revision 1.45

- and image is created with:
mkfs.jffs2 -e 131072 -r <dir> -o rootfs.jffs2

Am I missing something here?

regards,
hk
-- 
..because under Linux "if something is possible in principle,
then it is already implemented or somebody is working on it".

					--LKI

Re: jffs2 problem

[David Woodhouse]

On Wed, 2004-06-09 at 06:57 +0000, zhang hao wrote:
> Waiting for write to complete timed out in do_write_oneword.

Hmm. Does this still happen with code that isn't 18 months old?

-- 
dwmw2

jffs2 problem

[zhang hao]

Hi,

I use kernel 2.4.18 and mtd-snapshot-20030110. My flash is 16M AMD/Fujitsu 
flash.I update cfi_cmdset_0002.c from v1.61 to 1.63.

My partitions is:
bootloader 16k
kernel 2032k
rootfs 6M

If I boot up the board, problem appears like this:

"...........................................
Empty flash at 0x002fdffc ends at 0x002fe000
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 40k freed
init-2.05a# mount -t jffs2 /dev/mtdblock2 /tmp
Waiting for write to complete timed out in do_write_oneword.<5>Write of 68 
bytes at 0x002fe
514 failed. returned -5, retlen 0
Not marking the space at 0x002fe514 as dirty because the flash driver 
returned retlen zero
can't create lock file /etc/mtab~9: Input/output error (use -n flag to 
override)
init-2.05a# cd bin
Node CRC 27c9a666 != calculated CRC 3a68bebd for node at 0003567c
Node CRC 277ca666 != calculated CRC eab325e6 for node at 00035e18
Node CRC 27cea666 != calculated CRC 70c74bd7 for node at 000366bc
Node CRC 2784a666 != calculated CRC 44fe4247 for node at 00036e28
Node CRC 2771a666 != calculated CRC 14440ce0 for node at 00037554
Node CRC 270fa666 != calculated CRC 8df1f32c for node at 00037ce0
Node CRC 270ea666 != calculated CRC d639ca66 for node at 00038568
Node CRC 271fa666 != calculated CRC 56581f9a for node at 00038c44
Node CRC 271fa666 != calculated CRC 56581f9a for node at 00038c44
Node CRC 271fa666 != calculated CRC 56581f9a for node at 00038c44
Waiting for write to complete timed out in do_write_oneword.<5>Write of 68 
bytes at 0x002fe
514 failed. returned -5, retlen 4
Node CRC f61f06e7 != calculated CRC fc464067 for node at 00038c44
Node CRC f61f06e7 != calculated CRC fc464067 for node at 00038c44
................................................................."

any advice?
thanks.

               zhanghao

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn  

jffs2 problem

[aa aaa]

First ,thanks your instruction~~
My mainboard is rpxlite_dw ,kernel version is 2.4.18.
the flash is 16M on my board.

About the bd_info structure ,I have modified it just the same as u-boot.
"xd" comes into play after I run net_nfs.
the start address of flash memory is ff000000 in u-boot.

Thanks a lot!!

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

JFFS2 problem

[Michael Palme]

hello...

ive already posted this on arm-general, so please dont flame on me.

i've got a PXA263 board running 2.4.21-rmk1-pxa1 from U-Boot 1.0.2. i
use a JFFS2 rootfs. ive tried an image from the web (for wepep250) --
and it works without problems.

but i can't get "selfmade" images to run.

here is what ive done:

on my development system:

i took the working image from the web:
"dd if=working_img_from_web.jffs2 of=/dev/mtdblock0"

then i mount this:
"mount -t jffs2 /dev/mtdblock0 /mnt/mtd"

and copied everything out
"cp -R /mnt/mtd/* /tmp/content"

then i tried to recreate a jffs2 image from this (unchanged!)
"mkfs.jffs2 -o /tmp/test.jffs2 -r /tmp/content -e 256 -p"

after this i flashed this image with u-boot exactly the same way as the
working image.

then when trying to boot i get the following:


Starting kernel ...

Linux version 2.4.21-rmk1-pxa1-goepel1 (mic@palme) (gcc version 3.2.1)
#1 Don Mdr 18 17:42:30 CET 2004
CPU: XScale-PXA255 revision 6
Machine: Goepel electronic PXA263 ECU board
Ignoring unrecognised tag 0x00000000
Memory clock: 99.53MHz (*27)
Run Mode clock: 398.13MHz (*4)
Turbo Mode clock: 398.13MHz (*1.0, inactive)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock2 mem=64m console=ttyS00,115200n8
Calibrating delay loop... 397.31 BogoMIPS
Memory: 64MB = 64MB total
Memory: 63496KB available (1003K code, 237K data, 52K init)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis
Communications AB.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with no serial options enabled
ttyS00 at 0x0000 (irq = 15) is a PXA UART
ttyS01 at 0x0000 (irq = 14) is a PXA UART
ttyS02 at 0x0000 (irq = 13) is a PXA UART
Probing PXA263 internal flash at physical address 0x00000000 (32-bit
buswidth)
cfi_cmdset_0001: Erase suspend on write enabled
Using buffer write method
Using static partition definition
Creating 3 MTD partitions on "PXA263 internal flash":
0x00000000-0x00040000 : "Bootloader"
0x00040000-0x00200000 : "Kernel"
0x00200000-0x02000000 : "Filesystem"
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NetWinder Floating Point Emulator V0.97 (double precision)
VFS: Mounted root (jffs2 filesystem).
Mounted devfs on /dev
Freeing init memory: 52K
pc : [<00000034>]    lr : [<4006678c>]    Not tainted
sp : bffff8c0  ip : 4001f000  fp : bffffec4
r10: 40140284  r9 : bffffed0  r8 : 4013e89c
r7 : 0003db44  r6 : 0003db44  r5 : 0003db44  r4 : 00000000
r3 : 4013e89c  r2 : 00000000  r1 : 0003db44  r0 : 4013e89c
Flags: nZCv  IRQs on  FIQs on  Mode USER_32  Segment user
Control: 397F  Table: A000C000  DAC: 00000015
[again and again...]


ive tried several different mkfs.jffs2 binaries (and also a self- build
from mtd-cvs) from the web without success. i think this tools
(respective my handling of this tool) is the problem cause the content
of the working and the nonworking image is the same???

it would be very nice if somebody advice me what im doing wrong...

thanks in advance Michael Palme.

JFFS2 problem

[Vikram Mehta]

Hi people,

Let me discuss the problem with you and kindly tell me what is wrong here.
any ideas are welcome
When we mount jffs2 if the mount process ends up after the Garbage
collection thread is said to be sleeping, the mount is successful
However if in the mount process, jffs2_write_supper is called after GC
thread is sleeping, It calls a function to erase blocks by the name
jffs2_erase_pending_blocks.

If the code enters this function, it goes on to the scheduler
by the call stack
jffs2_erase_pending_blocks
jffs2_erase_block.
c->mtd->erase() which is
..
cfi_amdstd_erase_varsize
do_erase_one_block
cfi_udelay
udelay
scehdule_timeout
schedule
switch_to macro
where the system Crashes

I tried one thing. Commenting the jffs2_erase_block call in
jffs2_erase_pending_blocks.
Now my mount works perfectly fine.... Very nicely
But  now erase and eraseall /dev/mtdx  crash.
the crash in erase or eraseall
The crash in erase or eraseall follows the same call stack.

Any ideas what might be wrong .


Vikram

RE: JFFS2 Problem

[Frederic Giasson]

This reminds me of a problem which I think was fixed a long time ago
(probably around the end of July 2001).  I was copying and erasing
repeateadly a certain amount of small files and subdirectories, and free
space reported by "df" was constantly decreasing. The memory leak was
occuring upon directories deletion, the metadata was remaining on the flash.
The fix was done in clear_inode() function. 

If you are using an old version of JFFS2, maybe the fix was not present.
Originally, the patch was done in function jffs2_clear_inode(), file
readinode.c.  It has been moved to function jffs2_do_clear_inode() -
readinode.c:

	if (f->metadata) {
		if (!f->inocache->nlink)
			jffs2_mark_node_obsolete(c, f->metadata->raw);
		jffs2_free_full_dnode(f->metadata);
	}

Look in file readinode.c.  If you don't see the above code, you could try to
update you JFFS2 code and then look if the problem is gone.  If the fix is
in your code and the problem is still present, then I would appreciate if
you could explain to me how to reproduce your problem.

Frédéric Giasson 

jffs2 problem

[Wojciech Kromer]

I can't guess whats wrong with my jffs2.

My test:

sh-2.03# mount /dev/mtdblock0 /mnt -t jffs2
sh-2.03# cp ./vtxcsmod /mnt/lib/modules/vtxcsmod
sh-2.03# diff ./vtxcsmod /mnt/lib/modules/vtxcsmod
sh-2.03# umount /mnt
sh-2.03# mount /dev/mtdblock0 /mnt -t jffs2
sh-2.03# diff ./vtxcsmod /mnt/lib/modules/vtxcsmod
sh-2.03# umount /mnt

Then ... boot from jffs2 filesystem
Now:

sh-2.03# diff ./vtxcsmod /mnt/lib/modules/vtxcsmod
Binary files ./vtxcsmod and /mnt/lib/modules/vtxcsmod differ

?????????????????????????????????????????????????????????
Anyone could help???????????????????????????????????????

Maby this dmesg helps:

eb58->c1c8eb6c)
frag 62000-63000: 0x0071b500 on flash (*c1c8eb6c->c1c8eb80)
frag 63000-64000: 0x0071bbb0 on flash (*c1c8eb80->c1c8eb94)
frag 64000-65000: 0x0071c394 on flash (*c1c8eb94->c1c8eba8)
frag 65000-66000: 0x0071caf4 on flash (*c1c8eba8->c1c8ebbc)
frag 66000-67000: 0x0071d2cc on flash (*c1c8ebbc->c1c8ebd0)
frag 67000-68000: 0x0071db58 on flash (*c1c8ebd0->c1c8ebe4)
frag 68000-69000: 0x0071e374 on flash (*c1c8ebe4->c1c8ebf8)
frag 69000-6a000: 0x0071ec30 on flash (*c1c8ebf8->c1c8ec0c)
frag 6a000-6a2d2: 0x0071f4a8 on flash (*c1c8ec0c->00000000)
metadata @0071f738: ver 113
Truncating fraglist to 0x0006a2d2 bytes
jffs2_read_inode() returning
jffs2_do_readpage_nolock(): ino #125, page at offset 0x0
jffs2_readpage: offset 0, end 4096
Reading 0-4096 from node at 0x74bd68
Node read from 0074bd68: node_crc f8b1f05f, calculated CRC f8b1f05f.
dsize 1000, csize 833, offs
et 0, buf c1ef3000
Read 2099 bytes to c1cca000
Data CRC matches calculated CRC 7e703afe
Decompress 2099 bytes from c1cca000 to 4096 bytes at c1ef3000
node read done
node read was OK. Looping
readpage finishing
readpage finished
jffs2_do_readpage_nolock(): ino #125, page at offset 0x1000
jffs2_readpage: offset 4096, end 8192
Reading 4096-8192 from node at 0x74c5e0
Node read from 0074c5e0: node_crc a8574e85, calculated CRC a8574e85.
dsize 1000, csize 7ea, offs
et 1000, buf c1d28000
Read 2026 bytes to c017e800
Data CRC matches calculated CRC 3795f5dc
Decompress 2026 bytes from c017e800 to 4096 bytes at c1d28000
node read done
node read was OK. Looping
readpage finishing
readpage finished
jffs2_do_readpage_nolock(): ino #125, page at offset 0x2000
jffs2_readpage: offset 8192, end 12288
Reading 8192-12288 from node at 0x74ce10
Node read from 0074ce10: node_crc eb81d4ff, calculated CRC eb81d4ff.
dsize 1000, csize 88f, offs
et 2000, buf c1e70000
Read 2191 bytes to c1cca000
Data CRC matches calculated CRC 4fddb0be
Decompress 2191 bytes from c1cca000 to 4096 bytes at c1e70000
node read done
node read was OK. Looping
readpage finishing
readpage finished
jffs2_do_readpage_nolock(): ino #125, page at offset 0x3000
jffs2_readpage: offset 12288, end 16384
Reading 12288-16384 from node at 0x74d6e4
Node read from 0074d6e4: node_crc f52e964e, calculated CRC f52e964e.
dsize 1000, csize 7c4, offs
et 3000, buf c0352000
Read 1988 bytes to c017e800
Data CRC matches calculated CRC 507e1bc8
Decompress 1988 bytes from c017e800 to 4096 bytes at c0352000
node read done
node read was OK. Looping
readpage finishing
readpage finished
jffs2_do_readpage_nolock(): ino #125, page at offset 0x4000
jffs2_readpage: offset 16384, end 20480
Reading 16384-20480 from node at 0x74deec
Node read from 0074deec: node_crc bd20cd65, calculated CRC bd20cd65.
dsize 1000, csize 798, offs
et 4000, buf c1de6000
Read 1944 bytes to c1c58000
Data CRC matches calculated CRC d63432e1
Decompress 1944 bytes from c1c58000 to 4096 bytes at c1de6000
node read done
node read was OK. Looping
readpage finishing
readpage finished
jffs2_do_readpage_nolock(): ino #125, page at offset 0x5000
jffs2_readpage: offset 20480, end 24576
Reading 20480-24576 from node at 0x74e6c8
Node read from 0074e6c8: node_crc 4c220bd3, calculated CRC 4c220bd3.
dsize 1000, csize 785, offs
et 5000, buf c1dc0000
Read 1925 bytes to c017e800
Data CRC matches calculated CRC 9eac187d
Decompress 1925 bytes from c017e800 to 4096 bytes at c1dc0000
node read done
node read was OK. Looping
readpage finishing
readpage finished
jffs2_lookup()
Node read from 002d57d0: node_crc 91b489d2, calculated CRC 91b489d2.
dsize 4, csize 4, offset 0,
 buf c0283a40
Read 4 bytes to c0283a40
Data CRC matches calculated CRC ad373c97
Node read from 007ea318: node_crc b6948f45, calculated CRC b6948f45.
dsize c, csize c, offset 0,
 buf c0283a40
Read 12 bytes to c0283a40
Data CRC matches calculated CRC e3734b99
Node read from 002d57d0: node_crc 91b489d2, calculated CRC 91b489d2.
dsize 4, csize 4, offset 0,
 buf c0283a40
Read 4 bytes to c0283a40
Data CRC matches calculated CRC ad373c97
Node read from 007ea318: node_crc b6948f45, calculated CRC b6948f45.
dsize c, csize c, offset 0,
 buf c0283a40
Read 12 bytes to c0283a40
Data CRC matches calculated CRC e3734b99
Node read from 002d57d0: node_crc 91b489d2, calculated CRC 91b489d2.
dsize 4, csize 4, offset 0,
 buf c0283a40
Read 4 bytes to c0283a40
Data CRC matches calculated CRC ad373c97
Node read from 007ea318: node_crc b6948f45, calculated CRC b6948f45.
dsize c, csize c, offset 0,
 buf c0283a40
Read 12 bytes to c0283a40
Data CRC matches calculated CRC e3734b99
Node read from 006d4a64: node_crc 0d3d26b6, calculated CRC 0d3d26b6.
dsize b, csize b, offset 0,
 buf c0283a00
Read 11 bytes to c0283a00
Data CRC matches calculated CRC 1193fcf4
Node read from 005463f8: node_crc 15a926a2, calculated CRC 15a926a2.
dsize d, csize d, offset 0,
 buf c0283a40
Read 13 bytes to c0283a40
Data CRC matches calculated CRC 808bf9b7
jffs2_lookup()
jffs2_read_inode(): inode->i_ino == 389
getting inocache
jffs2_get_ino_cache(): ino 389
jffs2_get_ino_cache found c02c3f04 for ino 389
jffs2_read_inode(): Got inocache at c02c3f04
jffs2_read_inode(): ino #389 nlink is 1
jffs2_get_inode_nodes(): ino #389
Node at 002d5430 is a data node
version 1, highest_version now 1
dnode @002d5430: ver 1, offset 0000, dsize 0000
metadata @002d5430: ver 1
jffs2_read_inode() returning
Node read from 006d4a64: node_crc 0d3d26b6, calculated CRC 0d3d26b6.
dsize b, csize b, offset 0,
 buf c02838c0
Read 11 bytes to c02838c0
Data CRC matches calculated CRC 1193fcf4
Node read from 005463f8: node_crc 15a926a2, calculated CRC 15a926a2.
dsize d, csize d, offset 0,
 buf c0283880
Read 13 bytes to c0283880
Data CRC matches calculated CRC 808bf9b7
Node read from 002d57d0: node_crc 91b489d2, calculated CRC 91b489d2.
dsize 4, csize 4, offset 0,
 buf c02837c0
Read 4 bytes to c02837c0
Data CRC matches calculated CRC ad373c97
jffs2_lookup()
jffs2_read_inode(): inode->i_ino == 19
getting inocache
jffs2_get_ino_cache(): ino 19
jffs2_get_ino_cache found c0287f2c for ino 19
jffs2_read_inode(): Got inocache at c0287f2c
jffs2_read_inode(): ino #19 nlink is 1
jffs2_get_inode_nodes(): ino #19
Node at 007e8af4 is a data node
version 2, highest_version now 2
dnode @007e8af4: ver 2, offset 0000, dsize 000c
node at 0x007e8a74 is obsoleted. Ignoring.
jffs2_add_full_dnode_to_inode(ino #19, f c0fc0eb8, fn c029df30)
adding node 0000-000c @0x007e8af4 on flash, newfrag *c1c8ec20
frag 0000-000c: 0x007e8af4 on flash (*c1c8ec20->00000000)
jffs2_read_inode() returning
Node read from 007e8af4: node_crc 59509f00, calculated CRC 59509f00.
dsize c, csize c, offset 0,
 buf c02837c0
Read 12 bytes to c02837c0
Data CRC matches calculated CRC e3734b99
Node read from 002d57d0: node_crc 91b489d2, calculated CRC 91b489d2.
dsize 4, csize 4, offset 0,
 buf c02837c0
Read 4 bytes to c02837c0
Data CRC matches calculated CRC ad373c97
Node read from 007e8af4: node_crc 59509f00, calculated CRC 59509f00.
dsize c, csize c, offset 0,
 buf c02837c0
Read 12 bytes to c02837c0
Data CRC matches calculated CRC e3734b99
Node read from 002d57d0: node_crc 91b489d2, calculated CRC 91b489d2.
dsize 4, csize 4, offset 0,
 buf c02837c0
Read 4 bytes to c02837c0
Data CRC matches calculated CRC ad373c97
Node read from 007e8af4: node_crc 59509f00, calculated CRC 59509f00.
dsize c, csize c, offset 0,
 buf c02837c0
Read 12 bytes to c02837c0
Data CRC matches calculated CRC e3734b99
Node read from 006d4a64: node_crc 0d3d26b6, calculated CRC 0d3d26b6.
dsize b, csize b, offset 0,
 buf c0283780
Read 11 bytes to c0283780
Data CRC matches calculated CRC 1193fcf4
Node read from 005463f8: node_crc 15a926a2, calculated CRC 15a926a2.
dsize d, csize d, offset 0,
 buf c02837c0
Read 13 bytes to c02837c0
Data CRC matches calculated CRC 808bf9b7
--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom@dgt-lab.com.pl

Re: JFFS2 Problem

[David Woodhouse]

jsmith@vhbtech.com said:
>  I'm running jffs2 on a PPC/855T board. I mount the jffs2 and have two
> (2) test scripts that "dd" various sized files to the jffs2 flash. I
> seem to be running into a race condition or something.

> My 2 scripts just "dd" a bunch of files to the jffs2/flash, "ls -l "
> them, "rm *" them and then "ls -l" the dir/mnt point again in a loop.
> I'm running 2 of these and they always reach contention fairly
> quickly, ie. they lock up after 5 to 10 iterations. ps shows the
> processes sleeping. If I remove the "ls"portion of the scripts. That
> is I just "dd" and "rm" - everything "seems" ok.Anybody seen this? 

Sorry for the delayed response.

I've seen similar, and I thought I'd fixed it. You may have found a code 
path which I hadn't considered, and which still has locking problems. Or 
you may just be using the code from before I fixed it :)

What's the output of 'grep Id: fs/jffs2/*.[ch]'?

If it's still happening with the latest code, can you make sure you have 
SysRq enabled in your kernel and show me the backtraces of the offending 
processes? (SysRq-T and ksymoops for decoding)

--
dwmw2

JFFS2 Problem

[Jeff Smith]

Thanks to anyone who might offer some help for my problem.

I'm running jffs2 on a PPC/855T board. I mount the jffs2 and have
two (2) test scripts that "dd" various sized files to the jffs2 flash.
I seem to be running into a race condition or something.

My 2 scripts just "dd" a bunch of files to the jffs2/flash, "ls -l "
them,
"rm *" them and then "ls -l" the dir/mnt point again in a loop. I'm
running
2 of these and they always reach contention fairly quickly, ie.
they lock up after 5 to 10 iterations. ps shows the processes sleeping.
If I remove the "ls"portion of the scripts. That is I just "dd" and "rm"
-
everything "seems" ok.Anybody seen this?


Thanks Jeff

Re: jffs2 problem

[David Woodhouse]

decouto@lcs.mit.edu said:
>  i tried it again, but definitely erasing first.  similar thing:
> Argh. Special inode #1011 had more than one node

Very strange. Can you change DEFAULT_CONSOLE_LOGLEVEL to 8 in kernel/
printk.c, boot it and log all the messages? There'll be lots.


decouto@lcs.mit.edu said:
>  hmmm.  my last checkout and compile was say weds 21 march.

Ought to be OK. I haven't knowingly fixed something since then which I 
think could cause this behaviour.

What is ino #1101?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: jffs2 problem

[Douglas S. J. De Couto]

> >  is this likely to happen if i forgot to erase the flash with eflash
> > in the boat loader before loading the jffs2 image?  e.g. i had one
> > jffs2 image, and then i loaded another without eflashing.
> 
> Yes.

i tried it again, but definitely erasing first.  similar thing:

Argh. Special inode #1011 had more than one node
...

> A date should be sufficient.

hmmm.  my last checkout and compile was say weds 21 march.

[jffs2] bermuda% cat *.c *.h | grep Id:
 * $Id: background.c,v 1.10 2001/03/15 15:38:23 dwmw2 Exp $
 * $Id: build.c,v 1.16 2001/03/15 15:38:23 dwmw2 Exp $
 * $Id: compr.c,v 1.16 2001/03/15 15:38:23 dwmw2 Exp $
 * $Id: compr_rtime.c,v 1.5 2001/03/15 15:38:23 dwmw2 Exp $
 * $Id: compr_rubin.c,v 1.9 2001/03/15 15:38:23 dwmw2 Exp $
/* $Id: comprtest.c,v 1.4 2001/02/21 14:03:20 dwmw2 Exp $ */
 * $Id: compr_zlib.c,v 1.5 2001/03/15 15:38:24 dwmw2 Exp $
/* $Id: crc32.c,v 1.3 2001/02/07 16:45:32 dwmw2 Exp $ */
 * $Id: dir.c,v 1.38 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: erase.c,v 1.16 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: file.c,v 1.50 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: gc.c,v 1.47 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: ioctl.c,v 1.5 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: malloc.c,v 1.16 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: nodelist.c,v 1.27 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: nodemgmt.c,v 1.37 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: pushpull.c,v 1.6 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: read.c,v 1.11 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: readinode.c,v 1.54 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: scan.c,v 1.31 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: super.c,v 1.37 2001/03/19 23:21:31 dwmw2 Exp $
 * $Id: symlink.c,v 1.5 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: write.c,v 1.24 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: zlib.c,v 1.3 1997/12/23 10:47:42 paulus Exp $
/* $Id: compr_rubin.h,v 1.5 2001/02/26 13:50:01 dwmw2 Exp $ */
/* $Id: crc32.h,v 1.3 2001/02/26 14:44:37 dwmw2 Exp $ */
 * $Id: nodelist.h,v 1.44 2001/03/15 15:38:24 dwmw2 Exp $
 * $Id: pushpull.h,v 1.4 2001/03/15 15:38:24 dwmw2 Exp $
/*      $Id: zlib.h,v 1.2 1997/12/23 10:47:44 paulus Exp $      */

-- 
Douglas S. J. De Couto    decouto@lcs.mit.edu



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: jffs2 problem

[David Woodhouse]

decouto@lcs.mit.edu said:
>  is this likely to happen if i forgot to erase the flash with eflash
> in the boat loader before loading the jffs2 image?  e.g. i had one
> jffs2 image, and then i loaded another without eflashing.

Yes.

>  the kernel i compiled is from the handhelds.org CVS, and the CVS
> version is... well ther are a lot of files, so if you want to know a
> specific thing i can tell you. 

A date should be sufficient.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

jffs2 problem

[Douglas S. J. De Couto]

running jffs2 on ipaq with linux, get the following errors:


Argh. Special inode #1013 had more than one node
Argh. Special inode #1007 had more than one node
Argh. Special inode #1019 had more than one node
Argh. Special inode #1014 had more than one node
Argh. Special inode #1009 had more than one node
Argh. Special inode #1022 had more than one node
Argh. Special inode #1016 had more than one node
Argh. Special inode #1017 had more than one node
Argh. Special inode #1020 had more than one node

i am not really sure what the file system is supposed to be doing, QPE
is running....

is this likely to happen if i forgot to erase the flash with eflash in
the boat loader before loading the jffs2 image?  e.g. i had one jffs2
image, and then i loaded another without eflashing.  or is it a bug?

the jffs2 image was produced using mkfs.jffs2 with options 
``-p -e 0x40000'' 

the kernel i compiled is from the handhelds.org CVS, and the CVS
version is... well ther are a lot of files, so if you want to know a
specific thing i can tell you.

cheers

d

-- 
Douglas S. J. De Couto    decouto@lcs.mit.edu



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org