Problems with writing on jffs2

Problems with writing on jffs2

[Stefan Warmuth]

Hi all

I have trouble with our custom-made arm platform. We use a Intel SA-1110 
processor and Intel 28F640J3A Flash-Memory. We use 2.4.17-rmk5 kernel.

I made the image with,
mkfs.jffs2 -r source -o image.jffs2 -e 0x40000 -l -p
and flashed it into the memory and boot. All worked fine also on reboot.
Then i copied some files from the host into the flash and it workes also fine.
But on next reboot i got some errors and the system crashed.

jffs2_scan_dirent_node(): Name CRC failed on node at 0x00c00384: Read 
0x088b1c33
jffs2_scan_inode_node(): Data CRC failed on node at 0x00c4000c: Read 
0x2207d3bb3
jffs2_scan_dirent_node(): Name CRC failed on node at 0x00c821e0: Read 
0xb5211fe6
jffs2_scan_dirent_node(): Name CRC failed on node at 0x00dd8a80: Read 
0x9a7b54b2
jffs2_scan_inode_node(): Data CRC failed on node at 0x00e1e5e4: Read 
0x46eb4974c

I don't know where I am doing any wrong.

Have anybody an idea?

Thanks
Stefan

Re: Problems with writing on jffs2

[David Woodhouse]

On Mon, 8 Apr 2002, Stefan Warmuth wrote:

> Hi all
> 
> I have trouble with our custom-made arm platform. We use a Intel SA-1110 
> processor and Intel 28F640J3A Flash-Memory. We use 2.4.17-rmk5 kernel.

2.4.17-rmk5 unaligned fixups were broken. Upgrade.

-- 
dwmw2

Possible JFFS2 bug

[Charles Manning]

I'm not using JFFS2, but I happened to be reading the code in 2.4.18

In dir.c/jffs2_readdir()....

I notice that if the filldir returns <0 during the fill for "." and "..", the 
execution gotos out:. This bypasses the down() of the semaphore, however the 
semaphore still gets up()ed.

The up without a corresponding down was, I hunch, unintended.

Maybe someone using the code would like to take a look.


-- Charles

Re: Possible JFFS2 bug

[Elizabeth Clarke]

Charles Manning wrote:
> In dir.c/jffs2_readdir()....
> I notice that if the filldir returns <0 during the fill for "." and "..", the
> execution gotos out:. This bypasses the down() of the semaphore, however the
> semaphore still gets up()ed.

Looks like it was fixed in cvs:

revision 1.52
date: 2002/01/21 12:33:49;  author: dwmw2;  state: Exp;  lines: +3 -3
Fix bogus up() without down() in jffs2_readdir()

Beth

Possible JFFS2 bug

[Adrian Hunter]

I get the following trying to run
mtd-utils/tests/fs-tests/integrity/integck -n3


BUG: unable to handle kernel paging request at f8000000
IP: [<c020cb56>] crc32_le+0x36/0xe2
*pde = 00000000 
Oops: 0000 [#1] PREEMPT SMP 
Modules linked in: jffs2 nandsim nand nand_ids nand_ecc video output [last unloaded: jffs2]

Pid: 3761, comm: jffs2_gcd_mtd0 Not tainted (2.6.27-rc1ubifs30 #18)
EIP: 0060:[<c020cb56>] EFLAGS: 00010202 CPU: 0
EIP is at crc32_le+0x36/0xe2
EAX: c03339a7 EBX: c03339a7 ECX: 3f80cb89 EDX: 0000007f
ESI: f7fffffc EDI: ffffff8f EBP: f67fddfc ESP: f67fdde8
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process jffs2_gcd_mtd0 (pid: 3761, ti=f67fc000 task=f78a6130 task.ti=f67fc000)
Stack: 3fffffe3 f6032e94 ffffffd3 ffffff8f f67fdec0 f67fdee4 f88e9bf1 00000012 
       00000000 ffffff8f 00000001 f67fde7c f7371ad0 f67fde3c c0184332 00000000 
       f7323708 f604c7b4 f6d6d800 00000010 f7323708 f67fdea8 f88ebbd0 00000000 
Call Trace:
 [<f88e9bf1>] ? jffs2_garbage_collect_live+0xc5c/0xfef [jffs2]
 [<c0184332>] ? iget_locked+0x2a/0x12d
 [<f88ebbd0>] ? jffs2_iget+0xe/0x30d [jffs2]
 [<c011bed1>] ? __enqueue_entity+0xc3/0xee
 [<f88ea4c9>] ? jffs2_garbage_collect_pass+0x545/0x69c [jffs2]
 [<c012e909>] ? __sigqueue_free+0x2f/0x32
 [<c012e7f2>] ? recalc_sigpending+0xe/0x2f
 [<c038f6c1>] ? _spin_unlock_irq+0x8/0x28
 [<f88eb8bc>] ? jffs2_garbage_collect_thread+0x136/0x1a1 [jffs2]
 [<c0123f84>] ? __mmdrop+0x28/0x2f
 [<c011f2dc>] ? finish_task_switch+0x7f/0x85
 [<c011ff43>] ? schedule_tail+0x1a/0x4a
 [<c0103a66>] ? ret_from_fork+0x6/0x1c
 [<f88eb786>] ? jffs2_garbage_collect_thread+0x0/0x1a1 [jffs2]
 [<f88eb786>] ? jffs2_garbage_collect_thread+0x0/0x1a1 [jffs2]
 [<c010478f>] ? kernel_thread_helper+0x7/0x18
 =======================
Code: 89 cf f6 c2 03 0f 85 96 00 00 00 31 c0 83 ff 03 0f 97 c0 85 c0 74 62 89 f8 c1 e8 02 89 45 ec 83 ea 04 89 55 f0 89 d6 89 c1 89 
EIP: [<c020cb56>] crc32_le+0x36/0xe2 SS:ESP 0068:f67fdde8
---[ end trace 1097c72eb5c16624 ]---