The blocks are first marked in the RAM structures for retiring. Often this cannot be done immediately because there is stil data on the blocks. Thus it is deferred to being handled as part of a garbage collection.

If the RAM data is lost (eg. power cycle), then that is not a problem. This will be detected again on the next read.

Have a look at the HowYaffsWorks document. That might help explain things a bit more.

-- Charles


On Mon, Mar 5, 2018 at 7:59 PM, de Brebisson, Cyrille (Calculator Division) <cyrille@hp.com> wrote:

Hello,

 

Yet another question. When/How will the block that caused a read/write error be retired.

The issue at hand here is the following:

Read error occurs. Bad data is returned to the application that was reading the data. This causes a crash. Because we are on a small, one app RTOS, the whole system crashes.

If yaffs has “retired” the block “in it’s own private structures”, but not committed this to flash, then this “knowledge” will be lost and the block will not be retired.

 

Are we in this scenario?

 

Cyrille

 

De : de Brebisson, Cyrille (Calculator Division)
Envoyé : Thursday, March 01, 2018 7:09 AM
À : Charles Manning <cdhmanning@gmail.com>
Cc : yaffs@stoneboat.aleph1.co.uk
Objet : RE: [Yaffs] New to the mailing list. Have issues with bad flash reads

 

Hello,

 

I have some more questions that are popping up as I continue investigating this “flash read fails” issue.

You said that when bad read are detected, the block will be marked for later “cleanup”….

  • Do you mean that the block will be reused, or retired (marked as bad)
  • How is this done?
  • Is it done through internal YAFFS memory structures (which will not survive a “format through erase all blocks”)? Or is this done through a “bad block marking”?

In my latest test, I have 256 pages that return bad reads, in 4 different blocks

  • but I have not seen yaffs doing any bad block markings. Is this normal?
  • When will yaffs mark block as bad? In which condition and at what time?

 

Thanks,

Cyrille

 

De : yaffs [mailto:yaffs-bounces@stoneboat.aleph1.co.uk] De la part de de Brebisson, Cyrille (Calculator Division)
Envoyé : Thursday, February 22, 2018 7:37 AM
À : Charles Manning <cdhmanning@gmail.com>
Cc : yaffs@stoneboat.aleph1.co.uk
Objet : Re: [Yaffs] New to the mailing list. Have issues with bad flash reads

 

Hello,

 

Thank you for the info on yaffs’s handling of bad read. I understand what you mean here.

 

About the bad flash drivers.

  • One area where people often make mistakes is in waiting until the data is properly ready before reading.

I do not think that this is the issue as we are using a nand flash signal pin to know when data is ready to read

  • Also, make sure the flash memory power supplies are good and low ripple.

This sounds like a much more likely root cause in our case. I will investigate. Thanks for the pointer

 

Thanks for the info.

Have a good day.

Cyrille

 

De : Charles Manning [mailto:cdhmanning@gmail.com]
Envoyé : Wednesday, February 21, 2018 10:37 PM
À : de Brebisson, Cyrille (Calculator Division) <cyrille@hp.com>
Cc : yaffs@stoneboat.aleph1.co.uk
Objet : Re: [Yaffs] New to the mailing list. Have issues with bad flash reads

 

Hello

You really have two independent, but related issues going on here...

 

On Thu, Feb 22, 2018 at 4:45 AM, de Brebisson, Cyrille (Calculator Division) <cyrille@hp.com> wrote:

Hello,

 

I am responsible for implementing yaffs in a small, bare meta OS system with a 512MB, 2K pages, 64  pages block NAND Flash.

 

Our Flash rom subsystem is sometimes failing reads. This is happing on blocks that are supposed to be good and contains file data! Furthermore, later reads to the same page might succeed (after a system reboot).

 

Of course, this is wrecking havoc on our system’s reliability.

 

So, a couple of questions:

  • have you ever seen that in your experience?

 

Bad flash drivers are quite common. One area where people often make mistakes is in waiting until the data is properly ready before reading.

Also, make sure the flash memory power supplies are good and low ripple.  Remember that cells (and NAND flash cells in particular) are really analogue elements and too much ripple on the power rails can cause problems.

 

  •  
  • when this happen, I make sure that the flash driver to yaffs interface returns a YAFFS_FAIL, however, yaffs does seem to still return data to the user that called the file read, incorrectly returning known bad bytes at this point. Is this normal?

Yes, there is an issue here. Yaffs can choose to either say there is an IO error (EIO) or it can try to give back as much data as it can. Yaffs chooses the latter approach.

I have some changes underway to allow Yaffs to return EIO instead.

 

  •  
  • After such a bad read, yaffs does not seem to do anything on the block like mark it as bad or something like this. Is it intended?

It should be marked for future cleanup.

  •  

 

I am working with a checkout of yaffs which is around 6 month old (taken in june 2017) in a bare metal setup.

 

I doubt there are significant changes in the last 6 months to impact this issue.

The major thing to do is find out why the flash reads are failing so badly.

Regards

Charles