ubi corrupted list not counted as bad block

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi MTD Experts,

 I am hitting the below problem :
UBI assert failed in ubi_wl_init at line 1632
-> ubi_assert(ubi->good_peb_count == found_pebs);

The issue is because, in the scan_peb( ) , a specific PEB is found to
be corrupted in the volume header CRC calculation which is a
UBI_IO_BAD_HDR error.

Later in scan_peb ( ), my target hits the else part saying its an
unexpected corruption.
[attach.c]
else if (!err)
                        /* This corruption is caused by a power cut */
                        err = add_to_list(ai, pnum, UBI_UNKNOWN,
                                          UBI_UNKNOWN, ec, 1, &ai->erase);
                else {
                        /* This is an unexpected corruption */
                       err = add_corrupted(ai, pnum, ec);
                 }

The count of good peb is done as below :
/* code snippet in attach.c */
   ubi->bad_peb_count = ai->bad_peb_count; (this is 0 in my case)
   ubi->good_peb_count = ubi->peb_count - ubi->bad_peb_count;
(total_peb_count(3464) - 0 = 3464) but what about the corrupted one?
   ubi->corr_peb_count = ai->corr_peb_count;   (this is 1)

Why is
good_peb_count = peb_count - bad_peb_count ? (why not minus
corrupt_peb_count or add it to erase list?)

in the ubi_wl_init ( ) , the found_pebs is calculated from erase list
and free list and we skip the corrupted peb list. But the good_count
cotains the corrupted count as well.
So , i hit this problem ->
  ubi_assert(ubi->good_peb_count == found_pebs);

What is the logic behind this good_peb_count?

Thanks
bala

-- 
*This e-mail message is intended for the internal use of the intended 
recipient(s) only.
The information contained herein is 
confidential/privileged. Its disclosure or reproduction is strictly 
prohibited.
If you are not the intended recipient, please inform the sender 
immediately, do not disclose it internally or to third parties and destroy 
it.

In the course of our business relationship and for business purposes 
only, Valeo may need to process some of your personal data. 
For more 
information, please refer to the Valeo Data Protection Statement and 
Privacy notice available on Valeo.com 
<https://www.valeo.com/en/ethics-and-compliance/#principes>*

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux