From liushu@mprc.pku.edu.cn Tue May 20 02:20:06 2008 Received: from mprc.pku.edu.cn ([162.105.203.9]) by stoneboat.aleph1.co.uk with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JyGW5-0004NE-AF for yaffs@lists.aleph1.co.uk; Tue, 20 May 2008 02:20:03 +0100 Received: from mprcmmi90jbnb0 ([162.105.203.8]) by mprc.pku.edu.cn (8.13.8/8.13.8) with ESMTP id m4K1KN4e011160; Tue, 20 May 2008 09:20:24 +0800 Message-Id: <200805200120.m4K1KN4e011160@mprc.pku.edu.cn> From: "liushu" To: "'Matthias Fuchs'" Date: Tue, 20 May 2008 09:19:08 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200805191038.42546.matthias.fuchs@esd-electronics.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Thread-Index: Aci5jGDCnC6aSzqFTOuuAub/83ImDAAiS5BQ X-SA-Exim-Connect-IP: 162.105.203.9 X-SA-Exim-Mail-From: liushu@mprc.pku.edu.cn X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on stoneboat.aleph1.co.uk X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SA-Exim-Scanned: Yes (on stoneboat.aleph1.co.uk) Cc: yaffs@lists.aleph1.co.uk Subject: [Yaffs] =?gb2312?b?tPC4tDogbmFuZHNpbSt5YWZmczI=?= X-BeenThere: yaffs@lists.aleph1.co.uk X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of YAFFS NAND flash filesystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2008 01:20:07 -0000 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.=20 But write operations, such as cp or vi make the system crash. =20 I have checked, the error is in nandmtd2_WriteChunkWithTagsToNAND in yaffs_mtdif2. Here's the log:=20 dev: size erasesize name mtd0: 04000000 00020000 "NAND simulator partition 0"=20 kernel BUG at fs/yaffs2/yaffs_mtdif2.c:66! invalid opcode: 0000 [#1] SMP=20 Modules linked in: yaffs CPU: 0 EIP: 0060:[] 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=3Df623c000 task=3Df63b2ff0 = task.ti=3Df623c000) Stack: c0377650 00000000 00000000 c0377eb0 00000007 c2a22c00 00000800 c2af7800=20 00000000 f89b65bf c2a22c00 c0371bf6 f623dbe4 04000000 00000000 00001001=20 00000107 00000001 00000800 f623dc30 00000005 00000005 f623dc50 f89bd5e0=20 Call Trace: [] nand_release_device+0x4e/0x5b [] nand_write_oob+0xa7/0xb1 [] yaffs_CheckGarbageCollection+0x2c/0x98e [yaffs] [] part_write_oob+0x6e/0x7d [] nandmtd2_WriteChunkWithTagsToNAND+0x0/0xbc [yaffs] [] yaffs_WriteChunkWithTagsToNAND+0xcd/0xd5 [yaffs] [] yaffs_WriteNewChunkWithTagsToNAND+0x3b8/0x4f0 [yaffs] [] yaffs_WriteChunkDataToObject+0x75/0xb5 [yaffs] [] yaffs_WriteDataToFile+0x1fc/0x2d5 [yaffs] [] yaffs_commit_write+0xf7/0x218 [yaffs] [] generic_file_buffered_write+0x3ef/0x5d2 [] __d_lookup+0x96/0xd9 [] __generic_file_aio_write_nolock+0x4a6/0x505 [] yaffs_read_inode+0x11c/0x201 [yaffs] [] iget_locked+0x5e/0x113 [] inotify_d_instantiate+0x41/0x67 [] d_instantiate+0x3f/0x4b [] generic_file_aio_write+0x52/0xb0 [] do_sync_write+0xc7/0x10a [] autoremove_wake_function+0x0/0x35 [] add_partial+0xb/0x2a [] __slab_free+0x5c/0x241 [] lock_kernel+0x14/0x2e [] do_sync_write+0x0/0x10a [] vfs_write+0x8a/0x10c [] sys_write+0x41/0x67 [] sysenter_past_esp+0x5f/0x85 [] proc_dodebug+0xda/0x17e =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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=20 EIP: [] nandmtd2_WriteChunkWithTagsToNAND+0x61/0xbc [yaffs] = SS:ESP 0068:f623db78 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Matthias Fuchs = [mailto:matthias.fuchs@esd-electronics.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA5=D4=C219=C8=D5 16:39 =CA=D5=BC=FE=C8=CB: liushu =B3=AD=CB=CD: yaffs@lists.aleph1.co.uk =D6=F7=CC=E2: 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. > =20 > Thanks. > =20 > Lisa > =20 > =20 > =20 > =20 > =20 > =20 >=20 > -- Charles >=20 > On Friday 20 April 2007 21:36, you wrote:=20 > > On Thursday 19 April 2007 21:54, Charles Manning wrote:=20 > > > That would suggest to me that somehow the yaffs short op cache is > screwed > >=20 > > up.=20 > >=20 > > > The dd's you do:=20 > > > #dd if=3D/dev/zero of=3D/nand0/test1 bs=3D2k count=3Dxxx > > >=20 > > > are chunk aligned which means that you're bypassing the cache.=20 > > > If that theory holds, then > > > #dd if=3D/dev/zero of=3D/nand0/test1 bs=3D2k count=3D1000 will = work and it=20 > > > is not a file size issue. > >=20 > > It works.=20 > >=20 > > > What happens if you do > > > #dd if=3D/dev/zero of=3D/nand0/test1 bs=3D1k count=3D10 > >=20 > > That works, too!=20 > >=20 > > > That would force yaffs to use the cache and, I suspect might cause = > > > the > >=20 > > crash.=20 > >=20 > > But using a block size bigger or equal to 4k crashes the system:=20 > > #dd if=3D/dev/zero of=3D/nand0/test1 bs=3D4k count=3D10 > >=20 > > Exactly 4095 bytes is still ok:=20 > > #dd if=3D/dev/zero of=3D/nand0/test1 bs=3D4095 count=3D10 > >=20 > > > If this is happening then it is probably because the cache is not=20 > > > being allocated correctly and unfortunately there are insufficient = > > > checks in place to see that the malloc succeeded. There is some=20 > > > stuff I am working >=20 > > > on that fixes this and other issues but that won't be checked in=20 > > > for a while. > > >=20 > > > 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=20 > > > dev->off the >=20 > > > internal cache.=20 > >=20 > > I did the same tests with internal cache turned off. But it had no=20 > > impact on the issue. > >=20 > > Matthias >=20 >=20