Hi Jon,
also works on my PPC440EPx board.
Charles, I vote for this patch!
Matthias
On Monday 25 August 2008 16:56, Jon Fraser wrote:
> 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
> > >
> > >
> >
>
>
>
--
-------------------------------------------------------------------------
Dipl.-Ing. Matthias Fuchs
Head of System Design
esd electronic system design gmbh
Vahrenwalder Str. 207 - 30165 Hannover - GERMANY
Phone: +49-511-37298-0 - Fax: +49-511-37298-68
Please visit our homepage
http://www.esd.eu
Quality Products - Made in Germany
-------------------------------------------------------------------------
Geschäftsführer: Klaus Detering, Dr. Werner Schulze
Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832
-------------------------------------------------------------------------
(text/plain)