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!


> >
> > 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>