On Tue, 2009-02-10 at 00:49 -0500, Peter Barada wrote:

> On Tue, 2009-02-10 at 16:35 +1300, Charles Manning wrote: 
> 
> > On Tuesday 10 February 2009 14:26:47 Peter Barada wrote:
> > > On Tue, 2009-02-10 at 11:08 +1300, Charles Manning wrote:
> > > > On Tuesday 10 February 2009 07:02:05 Peter Barada wrote:
> > > > > I pulled a new copy of CVS YAFFS2 just after Charles added his patch
> > > > > for write_begin/write_end to build YAFFS for 2.6.28 kernels.
> > > >
> > > > <snip>
> > > >
> > > > > yaffs locking
> > > > > yaffs_mknod: making file
> > > > > yaffs_clear_inode: ino 1489, count 0 object exists
> > > > > yaffs locking
> > > > > yaffs_write_super
> > > > > yaffs_write_super
> > > > > yaffs_write_super
> > > > > yaffs_write_super
> > > > >
> > > > > It looks like a lookup for "Podgorica" came back as not there, but
> > > > > creating the object for "Podgorica" needs to clear the inode which
> > > > > tries to lock it, and YAFFS (and the upper FS layers) are wedged.
> > > > >
> > > > > Any ideas on how to fix this?
> > > >
> > > > Peter
> > > >
> > > > You say you pulled CVS just after I checked in the 2.6.28 stuff.
> > > >
> > > > A while later I checked in  change to yportenv.h
> > > >
> > > > http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs2/yportenv.h?r1=1.20&r2=
> > > >1.21
> > > >
> > > > This patch **should** fix what you're seeing.
> > >
> > > Still hangs, even with a fresh checkout of YAFFS2 from 19:41 EST
> > > (GMT-0500) that incorporates the patch to use GFP_NOFS on YMALLOC() (log
> > > from file operation before):
> 
> 
> Actually my bad.  Turns out LTIB creates dates in perl relative to
> GMT, not local, so the date flipped from 20090209 to 20090210 when I
> tried that fix at 17:41 EST (-0500), and since I was loading
> "yesterday's" version, it still failed.  Things work now with the
> change to pass GFP_NOFS to kmalloc()...
> 
> Thanks!


On further testing, I tried to re-untar the rootfs on top of the
previous untar'd instance in MTD, and I get BUGs, specifically
yaffs_guts.c:6836, and then twice at line 6763. Any idea why creating a
symbolic link, to replace a symbolic link, would trigger this?  The
results look look good(fromt he quick spot check I did).


> > >
> > > yaffs locking
> > > yaffs_lookup for 2945:Andorra
> > > yaffs unlocking
> > > yaffs_lookup not found
> > > yaffs_create
> > > yaffs_mknod: parent object 2945 type 3
> > > yaffs_mknod: making oject for Andorra, mode 81ed dev 0
> > > yaffs locking
> > > yaffs_mknod: making file
> > > yaffs unlocking
> > > yaffs_get_inode for object 2829
> > > yaffs_iget for 2829
> > > yaffs locking
> > > yaffs_FillInode mode 81ed uid 0 gid 0 size 0 count 1
> > > yaffs unlocking
> > > yaffs_mknod created object 2829 count = 1
> > > start yaffs_write_begin
> > > yaffs locking
> > > yaffs unlocking
> > > yaffs_readpage at 00000000, size 00001000
> > > yaffs locking
> > > yaffs unlocking
> > > yaffs_readpage done
> > > end yaffs_write_begin - ok
> > > yaffs_write_end addr c64a2000 pos 0 nBytes 2185
> > > yaffs locking
> > > yaffs_file_write about to write writing 2185 bytesto object 2829 at 0
> > > yaffs_file_write writing 2185 bytes, 2185 written at 0
> > > yaffs_file_write size updated to 2185 bytes, 5 blocks
> > > yaffs unlocking
> > > yaffs locking
> > > yaffs unlocking
> > > yaffs_file_flush object 2829 (dirty)
> > > yaffs locking
> > > yaffs unlocking
> > > yaffs_setattr of object 2829
> > > yaffs locking
> > > yaffs unlocking
> > > yaffs_setattr of object 2829
> > > yaffs locking
> > > yaffs unlocking
> > > yaffs_setattr of object 2829
> > > yaffs locking
> > > yaffs unlocking
> > > yaffs locking
> > > yaffs_lookup for 2945:Podgorica
> > > yaffs unlocking
> > > yaffs_lookup not found
> > > yaffs_create
> > > yaffs_mknod: parent object 2945 type 3
> > > yaffs_mknod: making oject for Podgorica, mode 81ed dev 0
> > > yaffs locking
> > > yaffs_mknod: making file
> > > yaffs_clear_inode: ino 1489, count 0 object exists
> > > yaffs locking
> > > yaffs_write_super
> > > yaffs_write_super
> > > yaffs_write_super
> > > yaffs_write_super
> > 
> > Hi Peter
> > 
> > Could you try adding a bit more tracing to the YMALLOC to verify that that is 
> > the chain that is causing the problem.
> > 
> > Also try extending the tracing  on the locking with something like:
> > static void yaffs_GrossLock(yaffs_Device * dev)
> > {
> >         T(YAFFS_TRACE_OS, (KERN_DEBUG "yaffs locking %p\n",current));
> >   
> >         down(&dev->grossLock);
> >         T(YAFFS_TRACE_OS, (KERN_DEBUG "yaffs locked %p\n",current)); 
> >  
> > }
> > 
> > static void yaffs_GrossUnlock(yaffs_Device * dev)
> > {
> >         T(YAFFS_TRACE_OS, (KERN_DEBUG "yaffs unlocking %p\n",current));
> >         up(&dev->grossLock);
> >  
> > }
> > 
> > that should confirm the chain for us.
> > 
> > Perhaps the NOFS flag is not being honoured the way that was being expected.
> > 
> > -- Charles
> > 
> 
> -- 
> Peter Barada <peterb@logicpd.com>
> 
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs

-- 
Peter Barada <peterb@logicpd.com>