Re: [Yaffs] [PATCH] Minor cleanup for yaffs bad block trace …

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: ian@brightstareng.com
Date:  
To: Jonathan McDowell
CC: yaffs
Subject: Re: [Yaffs] [PATCH] Minor cleanup for yaffs bad block trace error message
On Sunday 23 September 2007 17:15, Jonathan McDowell wrote:
> This is just a minor addition; the trace message for when
> yaffs marks a block bad doesn't have a newline on the end
> which causes output like:
>
> nand_erase: attempt to erase a bad block at page 0x000223e0


This doesn't look right - yaffs should not be erasing bad-blocks.
If the block just turned bad AND it got marked bad in MTD then
this might happen - but i don't think that's likely, and most MTD
setups don't have dynamic (mtd) bad-block-list update. This is
probably an indicator of some other issue, perhaps not reading
the true blockState during initial scan.

> **>> Erasure failed 4320
> yaffs: marking block 4319 bad<4>**>> Block 4320 retired


This is a side-effect of earlier attempt to erase bad-block.

> The attached patch fixes that.


Thanks for the newline!

> Also this set of messages is a bit confusing; the off by one
> appears to be due to yaffs_MarkBlockBad taking account of the
> dev->blockOffset field, but why does it do so when the other
> functions don't seem to?


I think this is covered by the ChunkInNAND = chunkInNAND -
dev->chunkOffset in the read and write functions, equivalent to
the blockOffset adjustment in the other functions in
yaffs_nand.c

-imcd