Hi Matthias,
Thanks for your reply. The test is ran on an x86 PC with 3GB RAM. I have
mounted the jffs2 filesystem on the nandsim device, and it works.
As for yaffs2, command "mount -t yaffs2 /dev/mtdblock0 /mnt" can be execute
correctly. The /mnt directory can be read. Command ls can dislaly the
"lost+found" directory.
But write operations, such as cp or vi make the system crash.
I have checked, the error is in nandmtd2_WriteChunkWithTagsToNAND in
yaffs_mtdif2.
Here's the log:
dev: size erasesize name
mtd0: 04000000 00020000 "NAND simulator partition 0"
kernel BUG at fs/yaffs2/yaffs_mtdif2.c:66!
invalid opcode: 0000 [#1]
SMP
Modules linked in: yaffs
CPU: 0
EIP: 0060:[<f89bd641>] Not tainted VLI
EFLAGS: 00010246 (2.6.23 #22)
EIP is at nandmtd2_WriteChunkWithTagsToNAND+0x61/0xbc [yaffs]
eax: 00000010 ebx: f689b000 ecx: 00000010 edx: f623dbb4
esi: 00000000 edi: f623dc50 ebp: f623dbb4 esp: f623db78
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process vim (pid: 3410, ti=f623c000 task=f63b2ff0 task.ti=f623c000)
Stack: c0377650 00000000 00000000 c0377eb0 00000007 c2a22c00 00000800
c2af7800
00000000 f89b65bf c2a22c00 c0371bf6 f623dbe4 04000000 00000000
00001001
00000107 00000001 00000800 f623dc30 00000005 00000005 f623dc50
f89bd5e0
Call Trace:
[<c0377650>] nand_release_device+0x4e/0x5b
[<c0377eb0>] nand_write_oob+0xa7/0xb1
[<f89b65bf>] yaffs_CheckGarbageCollection+0x2c/0x98e [yaffs]
[<c0371bf6>] part_write_oob+0x6e/0x7d
[<f89bd5e0>] nandmtd2_WriteChunkWithTagsToNAND+0x0/0xbc [yaffs]
[<f89bbd67>] yaffs_WriteChunkWithTagsToNAND+0xcd/0xd5 [yaffs]
[<f89b62db>] yaffs_WriteNewChunkWithTagsToNAND+0x3b8/0x4f0 [yaffs]
[<f89b855f>] yaffs_WriteChunkDataToObject+0x75/0xb5 [yaffs]
[<f89b8b9d>] yaffs_WriteDataToFile+0x1fc/0x2d5 [yaffs]
[<f89b3167>] yaffs_commit_write+0xf7/0x218 [yaffs]
[<c0148daf>] generic_file_buffered_write+0x3ef/0x5d2
[<c01720dd>] __d_lookup+0x96/0xd9
[<c0149438>] __generic_file_aio_write_nolock+0x4a6/0x505
[<f89b16b1>] yaffs_read_inode+0x11c/0x201 [yaffs]
[<c0173af0>] iget_locked+0x5e/0x113
[<c0185fc6>] inotify_d_instantiate+0x41/0x67
[<c017229c>] d_instantiate+0x3f/0x4b
[<c01494e9>] generic_file_aio_write+0x52/0xb0
[<c0163eed>] do_sync_write+0xc7/0x10a
[<c01347e9>] autoremove_wake_function+0x0/0x35
[<c015fc43>] add_partial+0xb/0x2a
[<c016087e>] __slab_free+0x5c/0x241
[<c04422e9>] lock_kernel+0x14/0x2e
[<c0163e26>] do_sync_write+0x0/0x10a
[<c0164666>] vfs_write+0x8a/0x10c
[<c0164bd0>] sys_write+0x41/0x67
[<c0104dae>] sysenter_past_esp+0x5f/0x85
[<c0440000>] proc_dodebug+0xda/0x17e
=======================
Code: c7 04 24 85 09 9c f8 89 44 24 04 e8 92 7a 76 c7 85 ff 74 13 8d 6c 24
3c 89 fa 89 e8 e8 62 e5 ff ff 85 f6 75 0a eb 04 0f 0b eb fe <0f> 0b eb fe c7
44 24 1c 01 00 00 00 c7 44 24 28 1c 00 00 00 8b
EIP: [<f89bd641>] nandmtd2_WriteChunkWithTagsToNAND+0x61/0xbc [yaffs] SS:ESP
0068:f623db78
-----邮件原件-----
发件人: Matthias Fuchs [
mailto:matthias.fuchs@esd-electronics.com]
发送时间: 2008年5月19日 16:39
收件人: liushu
抄送:
yaffs@lists.aleph1.co.uk
主题: Re: nandsim+yaffs2
Hi Lisa,
no this issue is not fixed. Your setup seems to be very different from mine.
What architecture are you runnung 2.6.23 on? How much memory do you have
installed?
Can you find out in which function your kernel crashes (backtrace?)?
Matthias
On Monday 19 May 2008 10:09, liushu wrote:
> Hi,
> I have got the similar problem when using yaffs2 on nandsim in
Linux2.6.23.
> Have this problem be fixed? I didn't find any related answer.
>
> Thanks.
>
> Lisa
>
>
>
>
>
>
>
> -- Charles
>
> On Friday 20 April 2007 21:36, you wrote:
> > On Thursday 19 April 2007 21:54, Charles Manning wrote:
> > > That would suggest to me that somehow the yaffs short op cache is
> screwed
> >
> > up.
> >
> > > The dd's you do:
> > > #dd if=/dev/zero of=/nand0/test1 bs=2k count=xxx
> > >
> > > are chunk aligned which means that you're bypassing the cache.
> > > If that theory holds, then
> > > #dd if=/dev/zero of=/nand0/test1 bs=2k count=1000 will work and it
> > > is not a file size issue.
> >
> > It works.
> >
> > > What happens if you do
> > > #dd if=/dev/zero of=/nand0/test1 bs=1k count=10
> >
> > That works, too!
> >
> > > That would force yaffs to use the cache and, I suspect might cause
> > > the
> >
> > crash.
> >
> > But using a block size bigger or equal to 4k crashes the system:
> > #dd if=/dev/zero of=/nand0/test1 bs=4k count=10
> >
> > Exactly 4095 bytes is still ok:
> > #dd if=/dev/zero of=/nand0/test1 bs=4095 count=10
> >
> > > If this is happening then it is probably because the cache is not
> > > being allocated correctly and unfortunately there are insufficient
> > > checks in place to see that the malloc succeeded. There is some
> > > stuff I am working
>
> > > on that fixes this and other issues but that won't be checked in
> > > for a while.
> > >
> > > Something else to try would be do look in yaffs_fs.c for where
> > > dev->nShortOpCaches is assigned and set that to zero. That turns
> > > dev->off the
>
> > > internal cache.
> >
> > I did the same tests with internal cache turned off. But it had no
> > impact on the issue.
> >
> > Matthias
>
>
(text/plain)