Infinite loop

[Frédéric SERGENT]

Hi Ricky and everyone,

so here's my first question to this list.

As Emmanuel briefly introduced me yesterday, I work with him, in the same company. I am currently taking over all what he already did to have UFFS working on our ecos platform, which is actually already pretty good! :-)

Right now, I mostly work on trying to use it in the most reliable way as we can. In that manner, I encountered a behaviour that looks quite odd to me, I will try to sum it up:
- create a file in a 'virgin' partition, fill it with 90KiB of data, not closing it, stopping device, restart it
- behaviour is different with different block sizes:
  * 1KiB pages / 64KiB blocks ==> file is recovered ok when restarting
  * 1KiB pages / 4KiB blocks  ==> file is not recovered ok, and we get into some kind of infinite loop.

Does that look familiar to anyone?

Here are more details:
- when dumping the content of our flash device, here is the difference between 64KiB and 4KiB blocks:
  * 64KiB blocks: content seems compliant with what I expected it to be.
  * 4KiB blocks: all DATA types blocks are filled OK. Only the FILE type block is not: the 1st page is OK with all info regarding the file itself, but the 3 following pages have obviously not been written (still full of FF FF)
- I suppose this is due to some kind of threshold triggering a flush of buffers above a certain size. This is ok to me
- what puzzles me more is the infinite loop that follows: one way to trigger it is to try to delete the incriminate file after rebooting and remounting the partition. When activating the debug traces, it seems clear that all DATA blocks get erased ok, but when dealing with the FILE block, we get into an infinite loop within the "while (flen > remain)" statement in do_TruncateObject: uffs_FindPageInBlockWithPageId can't get the right page.

Did anyone encounter this before?

Thanks in advance for any info, I'm still looking into it. :-)

Regards,
Fred

[Ricky Zheng]

Could you try to change MAX_DIRTY_BUF_GROUPS to 1, see if that fix your problem ?
My gut felling is that 4 pages/block configuration may have somehow conflict with 3 dirty groups.
By the way, are you running it on emulator ? I don't know any NAND flash with 1KiB page/4KiB block combination.

Cheers,
Ricky.

2011/12/22 Frédéric SERGENT <fred.se...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "UFFS" group.
To view this discussion on the web visit https://groups.google.com/d/msg/uffs/-/uv3VqR4YJz0J.
To post to this group, send email to uf...@googlegroups.com.
To unsubscribe from this group, send email to uffs+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/uffs?hl=en.

[Emmanuel Blot]

Hi Ricky,

> By the way, are you running it on emulator ? I don't know any NAND flash
> with 1KiB page/4KiB block combination.

We are not really using NAND flash devices with UFFS.

We are using serial flash devices: *25 series, mostly, from various
manufacturers. Those devices are not accessed through a parallel
interface, but over a SPI bus with a dedicated protocol. Erase blocks
range from 4KiB up to 64 KiB, while "pages" are mostly a virtual
concept as the flash device can be written from 1 byte up to 256
bytes.

However, the UFFS layer accesses the flash device through a generic
flash device driver that only expose 4KiB or 64 KiB erase blocks and
512-byte pages.

We are not using ECC, as these flash devices are guaranteed error-free
up to 100.000 erase cycles. There is no "spare" area either.

The exact underlying flash technology actually depends on the
manufacturer (for example, erasing a 64 KiB block takes from 50ms to
5s!), but it can be seen as NOR rather than NAND.

Nevertheless, UFFS perfectly fits our needs ;-)

Cheers,
Emmanuel.

[Frédéric SERGENT]

Hi Ricky,

thank you for the quick answer,

Could you try to change MAX_DIRTY_BUF_GROUPS to 1, see if that fix your problem ?
My gut felling is that 4 pages/block configuration may have somehow conflict with 3 dirty groups.

It does work. But it raises a few questions on my side, though:-). If I get things well:
- each element of dev->buf->dirtyGroup has a linked list of buffers, all UFFS_BUF_DIRTY, and all belonging to the same block in a given slot.
- all these dirty buffers are also in the linked list held by the struct uffs_PageBufDescSt member of the device (dev->buf->head and ...->tail)
- this list, by the way, plays the role of both a pool of UFFS_BUF_EMPTY buffers, and a kind of cache in reading (UFFS_BUF_VALID buffers) and in writing (UFFS_BUF_DIRTY buffers)
- having MAX_DIRTY_BUF_GROUPS==3 means we can have at most 3 blocks with dirty pages at the same time
- each of these can have at most MAX_DIRTY_PAGES_IN_A_BLOCK dirty pages at the same time.

I am not sure why lowering it to 1 leads us to flush the 1st block of the file being written? And actually, why out of all is that one not flushed at that moment (I would have thought it would have been the last one). But still, it does work.

Also, I suppose lowering MAX_DIRTY_PAGES_IN_A_BLOCK would work too?

 

By the way, are you running it on emulator ? I don't know any NAND flash with 1KiB page/4KiB block combination.

No, as Emmanuel explained, we use a kind of serial flash devices, but the way UFFS works perfectly matches our needs. This just led us to have our own data layout, which does not hold either block_status byte nor ecc.
Regarding the latter, we don't use the ecc field of the uffs_Tags received by our implementations of ReadPageWithLayout and WritePageWithLayout: as it is the last field in the structure, we replace its last byte by the newly added SEAL_BYTE, and restore it as TAG_ECC_DEFAULT at read time. This allows us to keep an 8 bytes spare area for each page.

Regards,
Fred

[Frédéric SERGENT]

I am not sure why lowering it to 1 leads us to flush the 1st block of the file being written? And actually, why out of all is that one not flushed at that moment (I would have thought it would have been the last one). But still, it does work.

Ok, I think I get it: if only one slot is available, it cannot stay occupied by the dirty content of the first block while we have more block to write after that. So in any case it will be flushed before even beginninig to write the content of block 2.
 

Also, I suppose lowering MAX_DIRTY_PAGES_IN_A_BLOCK would work too?

By the way, it probably means that if I write a very smal file (say, 2KiB, i.e. less than a full block including FILE type page), I might get the same behaviour. I will have to test that (I am not at work right now).