I ran across this problem on our MIPS HIGHMEM platfrom. My quick fix is listed below. Jon Fraser --- /work/linux/yaffs2/yaffs2//yaffs_fs.c 2008-05-05 03:58:58.000000000 -0400 +++ yaffs_fs.c 2008-08-04 19:20:22.000000000 -0400 @@ -685,7 +685,7 @@ unsigned to) { - void *addr = page_address(pg) + offset; + void *addr, *kva; loff_t pos = (((loff_t) pg->index) << PAGE_CACHE_SHIFT) + offset; int nBytes = to - offset; int nWritten; @@ -693,6 +693,9 @@ unsigned spos = pos; unsigned saddr = (unsigned)addr; + kva = kmap(pg); + addr = kva + offset; + T(YAFFS_TRACE_OS, (KERN_DEBUG "yaffs_commit_write addr %x pos %x nBytes %d\n", saddr, spos, nBytes)); @@ -710,6 +713,8 @@ SetPageUptodate(pg); } + kunmap(pg); + T(YAFFS_TRACE_OS, (KERN_DEBUG "yaffs_commit_write returning %d\n", nWritten == nBytes ? 0 : nWritten)); On Mon, 2008-08-25 at 11:29 +0200, Matthias Fuchs wrote: > Hi all, > > I totally ack with Ajit's description of the issue. > > There must be an issue with YAFFS when HIGHMEM is used on PowerPC systems. > I can imagine that there are not many systems out there with more than 768MB > RAM that are using YAFFS. So that's might be the cause why this issue has not > been observed by others until now. > > Matthias > > On Friday 22 August 2008 21:32, Ajit.Prem@emerson.com wrote: > > Hello, > > > > Does YAFFS2 work on boards which use HIGHMEM? I have a PowerPC board > > that comes in 1G and 2G variants. YAFFS works just fine on the 1G board > > and works just fine on the 2G board if I boot with mem=1G (HIGHMEM > > starts above 1G on this board). Everything but YAFFS work just fine on > > the 2G board when the full 2G is used, so there isn't a HIGHMEM issue on > > the board. > > > > YAFFS works well enough on these boards to allow using a root file > > system on NAND. However, when I try a simple write to a YAFFS partition > > on a 2G board configured to use the full 2G, I get the following crash. > > I don't seem to be the only one with this issue. My board is based on a > > dual-core 8641D PowerPC. Mathias Fuchs reported exactly the same problem > > on a 1G 44O board. The posting can be found with a google search for the > > item "HIGHMEM on 440EPx board with 1GB of RAM". On Matthias' board > > HIGHMEM started at 768M. When Matthias reconfigured his kernel so that > > he could use the full 1G as low memory, his YAFFS problems went away. > > > > > > # mount -t yaffs2 /dev/mtdblock4 /mnt > > # cd /mnt > > # cp -a /etc . > > > > ------------[ cut here ]------------ > > Kernel BUG at 8013cd0c [verbose debug info unavailable] > > Oops: Exception in kernel mode, sig: 5 [#1] > > PREEMPT SMP NR_CPUS=2 > > Modules linked in: > > NIP: 8013CD0C LR: 8013CD0C CTR: 8003E24C > > REGS: 8fb53a00 TRAP: 0700 Not tainted (2.6.20) > > MSR: 00029032 CR: 24422428 XER: 00000000 > > TASK = 842652d0[626] 'cp' THREAD: 8fb52000 CPU: 0 > > GPR00: 8013CD0C 8FB53AB0 842652D0 00000012 6419EFF8 F0266C8C 3F664DCF > > 00000000 > > GPR08: 00000610 00000000 10000000 8FB52000 38526268 10024A08 80400000 > > 00001000 > > GPR16: BD37E368 8FB53C38 8FB53C3C 00000000 00000000 00000000 8FB53BC0 > > 00000000 > > GPR24: 00000000 00000001 00000000 84272980 00000000 004C2000 8FB53BC0 > > BD318000 > > NIP [8013CD0C] nandmtd2_WriteChunkWithTagsToNAND+0xe8/0xf0 > > LR [8013CD0C] nandmtd2_WriteChunkWithTagsToNAND+0xe8/0xf0 > > Call Trace: > > [8FB53AB0] [8013CD0C] nandmtd2_WriteChunkWithTagsToNAND+0xe8/0xf0 > > (unreliable) > > [8FB53B10] [8013ACDC] yaffs_WriteChunkWithTagsToNAND+0x90/0x140 > > [8FB53B30] [80133C64] yaffs_WriteNewChunkWithTagsToNAND+0x3d4/0x538 > > [8FB53B70] [80135BE0] yaffs_WriteChunkDataToObject+0x94/0xe8 > > [8FB53C30] [80136304] yaffs_WriteDataToFile+0x214/0x2e0 > > [8FB53C90] [8012FE04] yaffs_commit_write+0x120/0x2bc > > [8FB53CD0] [800513D8] generic_file_buffered_write+0x3cc/0xa2c > > [8FB53D90] [80052E48] __generic_file_aio_write_nolock+0x314/0x5bc > > [8FB53E00] [80053158] generic_file_aio_write+0x68/0x10c > > [8FB53E30] [80078F88] do_sync_write+0xc0/0x134 > > [8FB53EF0] [80079628] vfs_write+0xf4/0x1bc > > [8FB53F10] [8007A210] sys_write+0x4c/0x90 > > [8FB53F40] [80011458] ret_from_syscall+0x0/0x38 > > --- Exception: c01 at 0xff69874 > > LR = 0x10008670 > > Instruction dump: > > 80010064 38210060 7c0803a6 4e800020 3c608038 386378bc 4bee9125 0fe00000 > > 48000000 3c608038 38637908 4bee9111 <0fe00000> 48000000 7c0802a6 > > 9421ff90 > > > > > > > > Some other info: > > > > -- part of boot log > > > > Creating 4 MTD partitions on "mvme7100-flash": > > 0x00000000-0x01000000 : "Linux Kernel + INITRD" > > 0x01000000-0x07e00000 : "Linux JFFS2 Filesystem" > > 0x07e00000-0x07f00000 : "Bootloader Block B" > > 0x07f00000-0x08000000 : "Bootloader Block A" > > NAND device: Manufacturer ID: 0xec, Chip ID: 0xd5 (Samsung NAND 4GiB > > 3,3V 8-bit) > > Scanning device for bad blocks > > Using static partition definition > > Creating 2 MTD partitions on "mvme7100-nand": > > 0x00000000-0x40000000 : "Linux" > > 0x40000000-0x80000000 : "Linux" > > > > > > # cat /proc/mtd > > dev: size erasesize name > > mtd0: 01000000 00040000 "Linux Kernel + INITRD" > > mtd1: 06e00000 00040000 "Linux JFFS2 Filesystem" > > mtd2: 00100000 00040000 "Bootloader Block B" > > mtd3: 00100000 00040000 "Bootloader Block A" > > mtd4: 40000000 00040000 "Linux" > > mtd5: 40000000 00040000 "Linux" > > > > Partitions mtd0->mtd3 are in NOR flash. Partitions mtd4 and mtd5 are in > > NAND flash. > > > > The flash part is Samsung K9KAG08U0M SLC flash. We use 4G and 8G > > variants. > > I have also had exactly the same problem using Samsung K9LBG08U0M MLC > > flash > > in 8G and 16G variants (no surprise). These flash parts have a 4K page > > size > > and 128 byte spare area. > > > > I have these problems using a Linux 2.6.20 kernel with a YAFFS snapshot > > from > > 8/15/2008, and also from another snapshot from sometime ago - yaffs > > versions below. > > > > cat /proc/yaffs > > YAFFS built:Aug 19 2008 10:45:21 > > $Id: yaffs_fs.c,v 1.63 2007/09/19 20:35:40 imcd Exp $ > > $Id: yaffs_guts.c,v 1.52 2007/10/16 00:45:05 charles Exp $ > > > > Any ideas on how I can fix this problem would be appreciated. > > > > Thanks, > > > > ap > > > > _______________________________________________ > > yaffs mailing list > > yaffs@lists.aleph1.co.uk > > http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > > > >