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 <EE,ME,IR,DR> 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
> >
> >
>
(text/plain)