Re: [Yaffs] Lockup in 2.6.28-rc8 (double lock)

トップ ページ
添付ファイル:
Eメールのメッセージ
+ (text/plain)
+ (text/html)
このメッセージを削除
このメッセージに返信
著者: Peter Barada
日付:  
To: Charles Manning
CC: yaffs
題目: Re: [Yaffs] Lockup in 2.6.28-rc8 (double lock)
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


--
Peter Barada <>