#1905 BLOC Trial-3: Field Return: flash corruption - OpenFirmware complaining of 'unknown node type 2006'.

[Zarro Boogs per Child]

#1905: Field Return: flash corruption - OpenFirmware complaining of 'unknown node
type 2006'.
----------------------+-----------------------------------------------------
  Reporter:  dwmw2    |       Owner:  dwmw2  
      Type:  defect   |      Status:  new    
  Priority:  blocker  |   Milestone:  Trial-3
 Component:  kernel   |     Version:         
Resolution:           |    Keywords:         
  Verified:  0        |  
----------------------+-----------------------------------------------------
Comment (by dwmw2):

 Replying to [comment:33 Luna]:
 >  Problem 1: ( Tested on the same CL1 )
 >
 >  If I execute command " nandwrite -p /dev/mtd" in OS, the CL1 will hang
 up in the process of   nand write.


 When we say 'hang up', we normally mean that the computer stops
 responding. Your problem1-1.JPG doesn't show that -- it just shows that
 the nandwrite program encountered an error and stopped. The kernel
 returned an error when asked to write a block of data to the flash. If you
 type 'dmesg' at this point, you might see warning messages from the
 kernel, describing the failure. Do you have the
 CONFIG_MTD_NAND_VERIFY_WRITE configuration option enabled?

 If this persists, we can make the kernel a little more verbose about such
 errors. Perhaps the nandwrite program ought to be marking the offending
 block as 'bad' when the write fails.


 >  Moreover, if I execute "copy-nand" under OFW, the nandwrite action
 keeps  going even  there is an error message (Refer to the
 attached:problem1-1, problem1-2.) and the machine can go into sugar
 successfully.
 >  But it will show a message: "Unsupported node type 2006" after reboot
 several times.

 That is a misleading error message. It _probably_ means you have similar
 corruption problems, but it's not clear. Can you verify whether the ECC
 data are correct for the affected blocks?

 >  I think the bad blocks are not marked well so it gets chance to write
 into the blocks which
 >  have problem

 Maybe. But if the ECC data on the flash match the data, that means that
 the corruption did not happen on the flash -- it happened in or before the
 CAFÉ chip.  And if not, then you're describing a different problem which
 should be in a different trac report.

 Please could you check the status of the ECC on the affected blocks, and
 the nature of the corruption (you could just let me have a copy of the
 image and the kernel's output when mounting it and I'll do the latter).

-- 
Ticket URL: <https://dev.laptop.org/ticket/1905#comment:35>
One Laptop Per Child <http://laptop.org/>