Re: [Yaffs] yaffs in CVS broken?

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Charles Manning
Date:  
To: yaffs
Subject: Re: [Yaffs] yaffs in CVS broken?
On Wednesday 19 November 2008 07:14:43 Rutger Hofman wrote:
> Charles Manning wrote:
> > On Wednesday 19 November 2008 05:34:48 Rutger Hofman wrote:
> >> I updated my checkout, and since that, after a while of running my basic
> >> test program spews:
> >>
> >> Writing -48 bytes to chunk!!!!!!!!!
> >>
> >> And it seems there are lots of blocks that are marked bad afterwards.
> >
> > Please email me your test (off list).
> >
> > Are you using yaffs1 or yaffs2 mode of operation?
> >
> > Bad blocks are usually a result of some lower level issue with the device
> > driver hosing the spare bytes.
>
> To make sure about the spare bytes, I check in 2 places whether a
> written data+spare are read back correctly by immediately reading them:
> in yaffs-fs.c, i.e. my eCos/YAFFS filesystem wrapper; and in my eCos
> NAND controller code. They compare identical in all cases. (This took
> some brain massage: memcmp() started reporting differences in the
> packedTag2 ecc field. But the only place where they turned out to differ
> is in the unused bytes for alignment between the starting unsigned char
> colParity and following unsigned lineParity).
>
> I am using the yaffs2 direct/ code. Depending on the history, sometimes
> my test completes correctly, and sometimes (e.g. after an erase of the
> nand chip) it gives this -48 bytes error after a while of testing.
>
> The test program just uses posix calls, it is my hacked-around version
> of a legacy eCos test program fileio1.c. Attached. I hope you can do
> something with some direct wrapper of your own... and that might be
> sufficiently different to make the problem go away of course. My nand
> chip is 2048Byte pages, a block is 64 pages, and I configure a YAFFS2
> file system on blocks 10 .. 26.
>


Can you try the patch in
http://www.aleph1.co.uk/lurker/message/20080928.082847.8b793974.en.html

I have not been able to reproduce this problem but perhaps you are reproducing
it here.

-- CHarles