Re: [Yaffs] YAFFS2 and HIGHMEM

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Ajit.Prem@Emerson.com
Date:  
To: jfraser, matthias.fuchs
CC: michael.sundius, dvomlehn, yaffs
Subject: Re: [Yaffs] YAFFS2 and HIGHMEM

Thanks for the fix. It works on my board.

Ajit


-----Original Message-----
From: Jon Fraser [mailto:jfraser@broadcom.com]
Sent: Monday, August 25, 2008 7:57 AM
To: Matthias Fuchs
Cc: ; Prem, Ajit [NETPWR/EMBED/AZ];
; David VomLehn
Subject: Re: [Yaffs] YAFFS2 and HIGHMEM

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, 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
> >
> > http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
> >
> >
>