#3247 BLOC MP Star: NAND rot

[Zarro Boogs per Child]

#3247: NAND rot
--------------------------------+-------------------------------------------
  Reporter:  wmb at firmworks.com  |       Owner:  mlj     
      Type:  defect             |      Status:  new     
  Priority:  blocker            |   Milestone:  MP Start
 Component:  hardware           |     Version:          
Resolution:                     |    Keywords:          
  Verified:  0                  |  
--------------------------------+-------------------------------------------

Comment(by wmb at firmworks.com):

 Replying to [comment:11 Luna]:
 > This happens just now.
 >
 > Machine number: C-1-07-M1(SHF73300012) ----->M1, which has problem.
 >
 > Use the machine(M1)
 > Do the "test /nandflash::fixbbt", first time can find the tool fix on
 one bad block and increase number of bad block.
 > Do the secone time, There is no increaser of bad block. Than key "boot"
 and wait a long time, find the machine M1 boot into sugar.
 >       God ~ what happen does the machine?

 One possible explanation:

 If there are NAND blocks that contain random data, such as is produced by
 the Linux-hosted nandtest program, OFW will take a very long time to boot.
 OFW can scan the NAND FLASH quickly when it sees valid JFFS2 data in a
 block and when it sees "ff" (erased) data.  But when it sees non-ff data
 that is not valid, it spends a long time searching the block hoping to
 find valid JFFS2 nodes in that data.  It will eventually finish the futile
 searches, but it can take many minutes.

 I plan to fix that in the next release, so that OFW will give up quickly
 on a block if it does not find valid JFFS2 data near the beginning.

 I do not know for sure that this is the problem you are seeing, but it is
 possible.

-- 
Ticket URL: <https://dev.laptop.org/ticket/3247#comment:13>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system