On Wed, 2009-02-11 at 04:42 +1300, Charles Manning wrote:

On Tuesday 10 February 2009 20:04:09 Peter Barada wrote:

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


Good to see it working... you had me scratching my head a bit there...

Same here. :)

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

I assume you see these in the trace during yaffs_clear_inode() or similar. For 
now just treat those bugs as warnings. they are checks that are going off but 
don't cater properly for some corner conditions on zombied objects (eg. 
checking for a sane well connected object that has been partially deleted). 
Something I should clean up...

They are quire messy as anytime a symbolic link is removed the messages pop out. Here's a simple testcase that triggers the messages:

# flash_eraseall /dev/mtd/3
# mkdir -p /mnt/fs
# mount -t yaffs /dev/mtdblock3 /mnt/fs
# ln -s /mnt/fs/foo /mnt/fs/bar
# rm /mnt/fs/bar

What's the best way to selectively suppress these messages (as they cloud the console output and will confuse users thinking their NAND is corrupted)? I say "selectively" as I think it would be good to have these messages come out under strain testing(some flag that can be set in /proc/yaffs?), but for regular use hide them...

-- Charles