j.chitte wrote:
> --- In Eddie Dawydiuk <> wrote:
> This utility should not be used to periodically repair
> bad blocks, if you are getting large amounts of bad blocks(>1-2%) then there
> is
> more than likely a bug somewhere or your writing huge amounts of data to Nand
> flash at a very fast rate(IIRC a 2KB block is guaranteed good for 10K writes).
> If you are truly getting bad blocks because they have been worn out, then you
> should not attempt to recover these blocks as they are truly bad and will lose
> data in the future.
>
> many thanks for all your detailed comments on your experiences with this
> problem.
>
> I originally replied to another thread about 6m ago about very long mounting
> delays on yaffs2. My TS7250 2kNAND board was taking over 90s to mount.
This is expected if the board is not shutdown properly. Yaffs2 adds
checkpointing support which speed up mount times dramatically when a checkpoint
has been written. Although, if a checkpoint has not been written Yaffs will
have
to rescan the entire contents of flash to determine the state of the flash
drive. The amount of time it takes to scan flash is directly proportional to
the
amount of data on the flash drive. A checkpoint is written when the Yaffs2
filesystem is unmounted or remounted read only. The shutdown scripts ensure a
checkpoint is written prior to rebooting / shutting down. Keep in mind if a
checkpoint was not written then that implies power was lost while the
filesystem
was mounted read write. If power was lost during an erase or write operation,
the sector being written / erased will be marked bad(assuming the operation did
not complete) the next time the Yaffs filesystem is mounted. This will happen
because Yaffs will not find a checkpoint and will scan the entire nand flash.
When the block being written/erased is encountered Yaffs will find a conflict
between the meta-data for the block and the actual contents of the block. As a
result Yaffs will mark the block as bad. One will continue to lose a block each
time power is lost during a write/erase operation.
> I would now be fairly sure that this is a precursor to the "tragic" failure I
> am now seeing.
Do your boards frequently lose power with out unmounting Yaffs or remounting it
read-only?
> I should point out that this board is still running an original ts 2.4 kernel
> (-ts12) , reading some of the threads on aleph1's site that I found googling
> this issue there have been several problems in this area , one of which was
> apparently adressed in an update only a few months ago. (june2009 from
> memory).
Hmmm, interesting. We are not aware of any bugs in the Yaffs filesystems we are
shipping in our default kernels(ts11). Please keep in mind ts11 is the current
shipping kernel, we have not released a ts12 kernel. This may be a problem in
that I can't comment on the stability of Yaffs2 in the ts12 kernel. Keep in
mind
we took a snapshot of the Yaffs code at a point in time and used that code for
our kernels. The TS-7260 was released several years ago, so the Yaffs
filesystem
we have in our kernel tree is most definitely different from the current
mainline kernel. As a result the same bugs/patches don't necessarily correspond
to the Yaffs filesystem in our kernel tree. If you could send me a link I could
take a look at the bug report to see if it applies...
> There are some circumstances in the use of this board that may bring out the
> bug.
>
> Occasional brown-outs that causes the 7250 to reboot.
>
> During testing , some abrupt power offs.
This is more than likely the problem. As I mentioned above if you are losing
power during write or erase operations you will mark a block as bad and you may
lose data in the case of the write operation.
> In view of the other poster , Gary, in the yaffs tragedy thread:
> http://tech.groups.yahoo.com/group/ts-7000/message/15589 who has three of
> these boards u/s with this problem and the significant number of returns you
> have on this , I'd say there is a real issue that needs thorough
> investigation here.
Thanks for the pointer, I'll respond to Gary's post. Although, please keep in
mind this is what I would consider a very mature product. That is we have not
made any kernel changes in years, and are unaware of any outstanding bugs.
> If you could look at that thread I am still having difficulty booting the
> vmlinux.bin you supply to run this tool.
It's been quite some time since I posted that kernel, so I don't recall what
board it was compiled for. I'd recommend grabbing the source tree and compiling
a kernel for your board.
--
Best Regards,
________________________________________________________________
Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
16525 East Laser Drive | fax: (480) 837-5300
Fountain Hills, AZ 85268 | web: www.embeddedARM.com
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|