Re: Bug in mtd_get_device_size()?

Re: Bug in mtd_get_device_size()?

[Brian Norris]

+ Richard

On Thu, Feb 28, 2013 at 4:30 AM, Velykokhatko, Sergey
<Sergey.Velykokhatko@mcc-med.de> wrote:
> I got today such case:
>
>       * Kernel 3.8
>
>       * We are using M29F2G16 NAND chip with 4096 blocks, each has 128k
>
>       * Configured with CONFIG_MTD_UBI_BEB_LIMIT=100

This is your problem. See below for more comments.

>       * Our rootfs partition contains 640 EBs
>
>       * At system start comes following error message:
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.375000] Creating 6 MTD
> partitions on "atmel_nand":
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.375000]
> 0x000000000000-0x000000020000 : "obsolete_bootstrap"
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.381000]
> 0x000000020000-0x000000320000 : "kernel_a"
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.386000]
> 0x000000320000-0x000000620000 : "kernel_b"
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.392000]
> 0x000000620000-0x000005620000 : "rootfs_a"
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.399000]
> 0x000005620000-0x00000a620000 : "rootfs_b"
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.406000]
> 0x00000a620000-0x000020000000 : "config_data"
>
> ...
>
>
>
> Feb 28 09:23:10 (none) kern.info kernel: [    0.546000] NET: Registered
> protocol family 17
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.557000] UBI: attaching
> mtd3 to ubi0
>
> Feb 28 09:23:10 (none) kern.info kernel: [    0.748000] usb 1-2: new
> high-speed USB device number 2 using atmel-ehci
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.810000] UBI: scanning is
> finished
>
> Feb 28 09:23:10 (none) kern.warn kernel: [    0.821000] UBI warning:
> print_rsvd_warning: cannot reserve enough PEBs for bad PEB handling,
> reserved 115, need 400
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: attached mtd3
> (name "rootfs_a", size 80 MiB) to ubi0
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: PEB size:
> 131072 bytes (128 KiB), LEB size: 129024 bytes
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: min./max. I/O
> unit sizes: 2048/2048, sub-page size 512
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: VID header
> offset: 512 (aligned 512), data offset: 2048
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: good PEBs:
> 640, bad PEBs: 0, corrupted PEBs: 0
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: user volume:
> 1, internal volumes: 1, max. volumes count: 128
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: max/mean
> erase counter: 399/202, WL threshold: 4096, image sequence number: 548304255
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: available
> PEBs: 0, total reserved PEBs: 640, PEBs reserved for bad PEB handling: 115
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.827000] UBI: background
> thread "ubi_bgt0d" started, PID 288
>
> UBI wanted to reserve 400 blocks on MTD with 640. Hm... During debugging I
> found that mtd_get_device_size() gives the size of whole flash memory back
> (4096 blocks * 128kB). I guess that I found small error. With micro patch
> the problem seems to be corrected for my case

Your patch is wrong, actually. mtd_get_device_size() should get "the
size of the entire flash chip", so if mtd is a partition, you *want*
to return the size of its 'master'.

In fact, everything is behaving as expected (by the designers; not by
you). Because your BEB_LIMIT=100, you are reserving 100*size/1024
(that is 9.8% of your total size, or 400 blocks) in *every* partition.
I don't see why you need that high of a limit, though. Check your NAND
data sheet, but the limit defaults reasonably to 20 (or, about 2%).
That would reserve only 80 blocks on your system, and you would not
see these warnings/errors, since you already have 115 blocks reserved.

You might want to read the comments in this commit:

commit ba4087e956d336488c6df9dfca65d1e70cf480f1
Author: Richard Genoud <richard.genoud@gmail.com>
Date:   Tue Jul 10 18:23:41 2012 +0200

    UBI: use the whole MTD device size to get bad_peb_limit

It might be worth revisiting the conclusions of those arguments; it
essentially limits your partitions to a certain minimum size. But as
far as I can tell, the code works as documented.

Brian

Re: Bug in mtd_get_device_size()?

[Richard Genoud]

2013/2/28 Brian Norris <computersforpeace@gmail.com>:
> + Richard
>
> On Thu, Feb 28, 2013 at 4:30 AM, Velykokhatko, Sergey
> <Sergey.Velykokhatko@mcc-med.de> wrote:
>> I got today such case:
>>
>>       * Kernel 3.8
>>
>>       * We are using M29F2G16 NAND chip with 4096 blocks, each has 128k
>>
>>       * Configured with CONFIG_MTD_UBI_BEB_LIMIT=100
>
> This is your problem. See below for more comments.
>
>>       * Our rootfs partition contains 640 EBs
>>
>>       * At system start comes following error message:
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.375000] Creating 6 MTD
>> partitions on "atmel_nand":
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.375000]
>> 0x000000000000-0x000000020000 : "obsolete_bootstrap"
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.381000]
>> 0x000000020000-0x000000320000 : "kernel_a"
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.386000]
>> 0x000000320000-0x000000620000 : "kernel_b"
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.392000]
>> 0x000000620000-0x000005620000 : "rootfs_a"
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.399000]
>> 0x000005620000-0x00000a620000 : "rootfs_b"
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.406000]
>> 0x00000a620000-0x000020000000 : "config_data"
>>
>> ...
>>
>>
>>
>> Feb 28 09:23:10 (none) kern.info kernel: [    0.546000] NET: Registered
>> protocol family 17
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.557000] UBI: attaching
>> mtd3 to ubi0
>>
>> Feb 28 09:23:10 (none) kern.info kernel: [    0.748000] usb 1-2: new
>> high-speed USB device number 2 using atmel-ehci
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.810000] UBI: scanning is
>> finished
>>
>> Feb 28 09:23:10 (none) kern.warn kernel: [    0.821000] UBI warning:
>> print_rsvd_warning: cannot reserve enough PEBs for bad PEB handling,
>> reserved 115, need 400
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: attached mtd3
>> (name "rootfs_a", size 80 MiB) to ubi0
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: PEB size:
>> 131072 bytes (128 KiB), LEB size: 129024 bytes
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: min./max. I/O
>> unit sizes: 2048/2048, sub-page size 512
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: VID header
>> offset: 512 (aligned 512), data offset: 2048
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: good PEBs:
>> 640, bad PEBs: 0, corrupted PEBs: 0
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: user volume:
>> 1, internal volumes: 1, max. volumes count: 128
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: max/mean
>> erase counter: 399/202, WL threshold: 4096, image sequence number: 548304255
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: available
>> PEBs: 0, total reserved PEBs: 640, PEBs reserved for bad PEB handling: 115
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.827000] UBI: background
>> thread "ubi_bgt0d" started, PID 288
>>
>> UBI wanted to reserve 400 blocks on MTD with 640. Hm... During debugging I
>> found that mtd_get_device_size() gives the size of whole flash memory back
>> (4096 blocks * 128kB). I guess that I found small error. With micro patch
>> the problem seems to be corrected for my case
>
> Your patch is wrong, actually. mtd_get_device_size() should get "the
> size of the entire flash chip", so if mtd is a partition, you *want*
> to return the size of its 'master'.
>
> In fact, everything is behaving as expected (by the designers; not by
> you). Because your BEB_LIMIT=100, you are reserving 100*size/1024
> (that is 9.8% of your total size, or 400 blocks) in *every* partition.
> I don't see why you need that high of a limit, though. Check your NAND
> data sheet, but the limit defaults reasonably to 20 (or, about 2%).
> That would reserve only 80 blocks on your system, and you would not
> see these warnings/errors, since you already have 115 blocks reserved.
That's rigth !
There's also some documentation on how the overhead is calculated here :
http://www.linux-mtd.infradead.org/doc/ubi.html#L_overhead
and some more explanations a little bellow, in the "Reserved blocks
for bad block handling" section

>
> You might want to read the comments in this commit:
>
> commit ba4087e956d336488c6df9dfca65d1e70cf480f1
> Author: Richard Genoud <richard.genoud@gmail.com>
> Date:   Tue Jul 10 18:23:41 2012 +0200
>
>     UBI: use the whole MTD device size to get bad_peb_limit
>
> It might be worth revisiting the conclusions of those arguments; it
> essentially limits your partitions to a certain minimum size. But as
> far as I can tell, the code works as documented.
>
> Brian



-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?

AW: Bug in mtd_get_device_size()?

[Velykokhatko, Sergey]

Hi Brian,

Thanks for your answer. Ok, I have nothing against that my interpretation of mtd_get_device_size() purpose is wrong. But what you mean under: "Because your BEB_LIMIT=100, you are reserving 100*size/1024 (that is 9.8% of your total size, or 400 blocks) in *every* partition." Looks for me a little bit strange. Why? Because I expected that UBI reserves the place for bad block handling pool depending on the size of MTD partition (on that it running) and not on the size of the whole chip. Actually I have 2 partitions with UBI (for rootfs and for data) and without my patch UBI tries to reserve nearly 400 blocks on each (see down). 

Why I set CONFIG_MTD_UBI_BEB_LIMIT to such high limit? Well, you are right: our NAND from production could contain up to 40 bad blocks. That is 1% of whole chip size. But our medical device should work in worst case each night for 10 years. I expect that in whole device life more blocks will be defect. Of course 10% for rootfs MTD is overkill since it will be updated very very seldom, but for data partititon 10% is probably even too low.  

>That would reserve only 80 blocks on your system, and you would not see these warnings/errors, since you already have 115 blocks reserved.
You mean *not on my system* but on each MTD running with UBI? :) Well I was thinking to divide my UBI volumes on UBI1 in small sub MTDs. Since I had 2 times cases, when I couldn't mount my ubi1:ubivol_data (I don't know why it happened, probably because of bugs in pretty new NAND driver from Atmel) and I should ubiformat/ubimkvolume for my MTD with loosing of extreme important data on ubi1:ubivol_device. If I really make new small MTDs for ubi1:ubivol_device/ ubi1:ubivol_config with the actual kernel state they will be completely used with poll for reserved bad blocks. No room for my data :) 

Best regards,
Sergey


/ # cd /sys/class/ubi/ubi0
/sys/devices/virtual/ubi/ubi0 # cat reserved_for_bad 
384
/sys/devices/virtual/ubi/ubi0 # cd ../ubi1/
/sys/devices/virtual/ubi/ubi1 # cat reserved_for_bad 
396
/sys/devices/virtual/ubi/ubi1 # df -h
Filesystem                Size      Used Available Use% Mounted on
ubi0:root-volume         27.2M     27.2M         0 100% /
devtmpfs                 29.3M         0     29.3M   0% /dev
tmpfs                    29.5M     64.0K     29.4M   0% /tmp
ubi1:ubivol_device        2.0M     24.0K      1.8M   1% /mnt/device
ubi1:ubivol_config        2.0M     36.0K      1.8M   2% /mnt/config
ubi1:ubivol_data        214.8M   1008.0K    209.1M   0% /mnt/data
/dev/mtdblock10          51.9M         0     51.9M   0% /mnt/masstorage
tmpfs                    29.5M     80.0K     29.4M   0% /run



-----Ursprüngliche Nachricht-----
Von: Brian Norris [mailto:computersforpeace@gmail.com] 
Gesendet: Donnerstag, 28. Februar 2013 18:25
An: Velykokhatko, Sergey
Cc: linux-mtd@lists.infradead.org; linux-kernel@vger.kernel.org; artem.bityutskiy@linux.intel.com; Richard Genoud
Betreff: Re: Bug in mtd_get_device_size()?

+ Richard

On Thu, Feb 28, 2013 at 4:30 AM, Velykokhatko, Sergey <Sergey.Velykokhatko@mcc-med.de> wrote:
> I got today such case:
>
>       * Kernel 3.8
>
>       * We are using M29F2G16 NAND chip with 4096 blocks, each has 
> 128k
>
>       * Configured with CONFIG_MTD_UBI_BEB_LIMIT=100

This is your problem. See below for more comments.

>       * Our rootfs partition contains 640 EBs
>
>       * At system start comes following error message:
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.375000] Creating 6 MTD
> partitions on "atmel_nand":
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.375000]
> 0x000000000000-0x000000020000 : "obsolete_bootstrap"
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.381000]
> 0x000000020000-0x000000320000 : "kernel_a"
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.386000]
> 0x000000320000-0x000000620000 : "kernel_b"
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.392000]
> 0x000000620000-0x000005620000 : "rootfs_a"
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.399000]
> 0x000005620000-0x00000a620000 : "rootfs_b"
>
> Feb 28 09:23:09 (none) kern.notice kernel: [    0.406000]
> 0x00000a620000-0x000020000000 : "config_data"
>
> ...
>
>
>
> Feb 28 09:23:10 (none) kern.info kernel: [    0.546000] NET: Registered
> protocol family 17
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.557000] UBI: attaching
> mtd3 to ubi0
>
> Feb 28 09:23:10 (none) kern.info kernel: [    0.748000] usb 1-2: new
> high-speed USB device number 2 using atmel-ehci
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.810000] UBI: scanning is
> finished
>
> Feb 28 09:23:10 (none) kern.warn kernel: [    0.821000] UBI warning:
> print_rsvd_warning: cannot reserve enough PEBs for bad PEB handling, 
> reserved 115, need 400
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: attached mtd3
> (name "rootfs_a", size 80 MiB) to ubi0
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: PEB size:
> 131072 bytes (128 KiB), LEB size: 129024 bytes
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: min./max. I/O
> unit sizes: 2048/2048, sub-page size 512
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: VID header
> offset: 512 (aligned 512), data offset: 2048
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: good PEBs:
> 640, bad PEBs: 0, corrupted PEBs: 0
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: user volume:
> 1, internal volumes: 1, max. volumes count: 128
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: max/mean
> erase counter: 399/202, WL threshold: 4096, image sequence number: 
> 548304255
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: available
> PEBs: 0, total reserved PEBs: 640, PEBs reserved for bad PEB handling: 
> 115
>
> Feb 28 09:23:10 (none) kern.notice kernel: [    0.827000] UBI: background
> thread "ubi_bgt0d" started, PID 288
>
> UBI wanted to reserve 400 blocks on MTD with 640. Hm... During 
> debugging I found that mtd_get_device_size() gives the size of whole 
> flash memory back
> (4096 blocks * 128kB). I guess that I found small error. With micro 
> patch the problem seems to be corrected for my case

Your patch is wrong, actually. mtd_get_device_size() should get "the size of the entire flash chip", so if mtd is a partition, you *want* to return the size of its 'master'.

In fact, everything is behaving as expected (by the designers; not by you). Because your BEB_LIMIT=100, you are reserving 100*size/1024 (that is 9.8% of your total size, or 400 blocks) in *every* partition.
I don't see why you need that high of a limit, though. Check your NAND data sheet, but the limit defaults reasonably to 20 (or, about 2%).
That would reserve only 80 blocks on your system, and you would not see these warnings/errors, since you already have 115 blocks reserved.

You might want to read the comments in this commit:

commit ba4087e956d336488c6df9dfca65d1e70cf480f1
Author: Richard Genoud <richard.genoud@gmail.com>
Date:   Tue Jul 10 18:23:41 2012 +0200

    UBI: use the whole MTD device size to get bad_peb_limit

It might be worth revisiting the conclusions of those arguments; it essentially limits your partitions to a certain minimum size. But as far as I can tell, the code works as documented.

Brian

AW: Bug in mtd_get_device_size()?

[Velykokhatko, Sergey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 6165 bytes --]

Hi Richard,

Thanks, I saw that definition and calculation formula. But it is ambiguous. Depending on what you take for basis for that 1024. If you take MTD size you get completely other result as for basis with whole chip size. In my interpretation of actual implementation the basis of whole chip size for this case is totally wrong since it brings limitations of minimum partition size driven with UBI (someone from you already listed this argument too). In my case I patched this thing in mtd_get_device_size(). I understand that patch is wrong for complete system in your interpretation. But I report you my problem case, listed you my arguments and you decide what to do. In "our" 3.8 Kernel I left my patch since now system works so as I expected. 

Thanks a lot,
Best regards,
Sergey



-----Ursprüngliche Nachricht-----
Von: Richard Genoud [mailto:richard.genoud@gmail.com] 
Gesendet: Freitag, 1. März 2013 09:11
An: Brian Norris
Cc: Velykokhatko, Sergey; linux-mtd@lists.infradead.org; linux-kernel@vger.kernel.org; artem.bityutskiy@linux.intel.com
Betreff: Re: Bug in mtd_get_device_size()?

2013/2/28 Brian Norris <computersforpeace@gmail.com>:
> + Richard
>
> On Thu, Feb 28, 2013 at 4:30 AM, Velykokhatko, Sergey 
> <Sergey.Velykokhatko@mcc-med.de> wrote:
>> I got today such case:
>>
>>       * Kernel 3.8
>>
>>       * We are using M29F2G16 NAND chip with 4096 blocks, each has 
>> 128k
>>
>>       * Configured with CONFIG_MTD_UBI_BEB_LIMIT=100
>
> This is your problem. See below for more comments.
>
>>       * Our rootfs partition contains 640 EBs
>>
>>       * At system start comes following error message:
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.375000] Creating 6 MTD
>> partitions on "atmel_nand":
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.375000]
>> 0x000000000000-0x000000020000 : "obsolete_bootstrap"
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.381000]
>> 0x000000020000-0x000000320000 : "kernel_a"
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.386000]
>> 0x000000320000-0x000000620000 : "kernel_b"
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.392000]
>> 0x000000620000-0x000005620000 : "rootfs_a"
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.399000]
>> 0x000005620000-0x00000a620000 : "rootfs_b"
>>
>> Feb 28 09:23:09 (none) kern.notice kernel: [    0.406000]
>> 0x00000a620000-0x000020000000 : "config_data"
>>
>> ...
>>
>>
>>
>> Feb 28 09:23:10 (none) kern.info kernel: [    0.546000] NET: Registered
>> protocol family 17
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.557000] UBI: attaching
>> mtd3 to ubi0
>>
>> Feb 28 09:23:10 (none) kern.info kernel: [    0.748000] usb 1-2: new
>> high-speed USB device number 2 using atmel-ehci
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.810000] UBI: scanning is
>> finished
>>
>> Feb 28 09:23:10 (none) kern.warn kernel: [    0.821000] UBI warning:
>> print_rsvd_warning: cannot reserve enough PEBs for bad PEB handling, 
>> reserved 115, need 400
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: attached mtd3
>> (name "rootfs_a", size 80 MiB) to ubi0
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: PEB size:
>> 131072 bytes (128 KiB), LEB size: 129024 bytes
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: min./max. I/O
>> unit sizes: 2048/2048, sub-page size 512
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: VID header
>> offset: 512 (aligned 512), data offset: 2048
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: good PEBs:
>> 640, bad PEBs: 0, corrupted PEBs: 0
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: user volume:
>> 1, internal volumes: 1, max. volumes count: 128
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: max/mean
>> erase counter: 399/202, WL threshold: 4096, image sequence number: 
>> 548304255
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.826000] UBI: available
>> PEBs: 0, total reserved PEBs: 640, PEBs reserved for bad PEB 
>> handling: 115
>>
>> Feb 28 09:23:10 (none) kern.notice kernel: [    0.827000] UBI: background
>> thread "ubi_bgt0d" started, PID 288
>>
>> UBI wanted to reserve 400 blocks on MTD with 640. Hm... During 
>> debugging I found that mtd_get_device_size() gives the size of whole 
>> flash memory back
>> (4096 blocks * 128kB). I guess that I found small error. With micro 
>> patch the problem seems to be corrected for my case
>
> Your patch is wrong, actually. mtd_get_device_size() should get "the 
> size of the entire flash chip", so if mtd is a partition, you *want* 
> to return the size of its 'master'.
>
> In fact, everything is behaving as expected (by the designers; not by 
> you). Because your BEB_LIMIT=100, you are reserving 100*size/1024 
> (that is 9.8% of your total size, or 400 blocks) in *every* partition.
> I don't see why you need that high of a limit, though. Check your NAND 
> data sheet, but the limit defaults reasonably to 20 (or, about 2%).
> That would reserve only 80 blocks on your system, and you would not 
> see these warnings/errors, since you already have 115 blocks reserved.
That's rigth !
There's also some documentation on how the overhead is calculated here :
http://www.linux-mtd.infradead.org/doc/ubi.html#L_overhead
and some more explanations a little bellow, in the "Reserved blocks for bad block handling" section

>
> You might want to read the comments in this commit:
>
> commit ba4087e956d336488c6df9dfca65d1e70cf480f1
> Author: Richard Genoud <richard.genoud@gmail.com>
> Date:   Tue Jul 10 18:23:41 2012 +0200
>
>     UBI: use the whole MTD device size to get bad_peb_limit
>
> It might be worth revisiting the conclusions of those arguments; it 
> essentially limits your partitions to a certain minimum size. But as 
> far as I can tell, the code works as documented.
>
> Brian



--
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: Bug in mtd_get_device_size()?

[Richard Genoud]

2013/3/1 Velykokhatko, Sergey <Sergey.Velykokhatko@mcc-med.de>:
> Hi Brian,
>
> Thanks for your answer. Ok, I have nothing against that my interpretation of mtd_get_device_size() purpose is wrong. But what you mean under: "Because your BEB_LIMIT=100, you are reserving 100*size/1024 (that is 9.8% of your total size, or 400 blocks) in *every* partition." Looks for me a little bit strange. Why? Because I expected that UBI reserves the place for bad block handling pool depending on the size of MTD partition (on that it running) and not on the size of the whole chip. Actually I have 2 partitions with UBI (for rootfs and for data) and without my patch UBI tries to reserve nearly 400 blocks on each (see down).
Reserving bad blocks depending on the size of the MTD partition is
wrong, and here is why:
I didn't checked the datasheet of your nand chipset (actually, I
didn't found it).
But let's say it's a standard one : your chip has 4096 blocks, and the
manufacturer says that there won't be more than 80 bad blocks
(20/1024)on the device during its ENDURANCE LIFE (endurance life means
something like 100000 program/erase cylcles).
Those 80 bad blocks could appear *everywhere*, they won't be equally
disposed on the device.
=> If you have a small bare MTD partition of 16blocks, and do a lot of
write/erase cycles on it, we can imagine that there will be some bad
blocks on it, and maybe all those 16 blocks will turn bad.
If UBI takes the size of MTD partition to compute the maximum number
of bad erase blocks, for a 16blocks MTD partition, this would be
16*20/1024 =0.31 => there will be a lack of reserved erase blocks.
said differently: if you want to be sure to have 2MB space (16blocks)
to write on, you have to reserve 80 blocks more. This is the worst
case scenario.
>
> Why I set CONFIG_MTD_UBI_BEB_LIMIT to such high limit? Well, you are right: our NAND from production could contain up to 40 bad blocks. That is 1% of whole chip size. But our medical device should work in worst case each night for 10 years. I expect that in whole device life more blocks will be defect. Of course 10% for rootfs MTD is overkill since it will be updated very very seldom, but for data partititon 10% is probably even too low.
"I expect that in whole device life more blocks will be defect."
you have to double check that.
In all nand datasheets that I've seen, the given number was for the
endurance life.
>From a Micron Nand datasheet :
Micron NAND devices are specified to have a minimum of 2,008 (NVB)
valid blocks out
of every 2,048 total available blocks. This means the devices may have
blocks that are
invalid when they are shipped. An invalid block is one that contains
one or more bad
bits. Additional bad blocks may develop with use. However, the total
number of avail-
able blocks will not fall below NVB during the endurance life of the product.

As there's very little information on how bad blocks appear, we can
suppose that even on the 1st erase cycle of a block, it can turn bad.
That's why we have to use the worst case scenario.
>
>>That would reserve only 80 blocks on your system, and you would not see these warnings/errors, since you already have 115 blocks reserved.
> You mean *not on my system* but on each MTD running with UBI? :) Well I was thinking to divide my UBI volumes on UBI1 in small sub MTDs. Since I had 2 times cases, when I couldn't mount my ubi1:ubivol_data (I don't know why it happened, probably because of bugs in pretty new NAND driver from Atmel) and I should ubiformat/ubimkvolume for my MTD with loosing of extreme important data on ubi1:ubivol_device. If I really make new small MTDs for ubi1:ubivol_device/ ubi1:ubivol_config with the actual kernel state they will be completely used with poll for reserved bad blocks. No room for my data :)

yes, using a lot of UBI partition is not space friendly.
The optimized way is one UBI partition, and many ubi volumes...

By the way,  even your kernel_a partition can be seen as undersized
(3MB). if your kernel is 2MB, there's only 1MB (8) left for eventual
bad blocks.
I understands that it's "unlikely" that more than 8 bad blocks appears
on a partition where you do not write very often, that this would be
"bad luck", but who knows...
That will depend on the criticality of your device, "do we accept to
may be brick one product out of xxxxx or not ?". If not, we have to
accept to loose some space for bad blocks, or use NOR :)

Best regards,
Richard.

AW: Bug in mtd_get_device_size()?

[Velykokhatko, Sergey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 6271 bytes --]

Hi Richard,

Thanks a lot for your explanations. Now at least I understand your logic. And it seems to be reasonable. Your start point that all bad blocks for flash chip could be placed in single MTD. This is really worst worst case, but... Theoretically it could happened. And you should take care of it. 
And you are right again in things about my chip. I interpreted that up to 40 blocks could be bad from chip production. But now found on side 104 of 125 one note (sometimes I like datasheets :-) ):

"
Notes:
 1. Invalid blocks are blocks that contain one or more bad bits. The device may contain bad
blocks upon shipment. Additional bad blocks may develop over time; however, the total
number of available blocks will not drop below NVB during the endurance life of the
device. Do not erase or program blocks marked invalid by the factory.
"

Also I should expect up to 40 bad blocks. Nearly 1%.  No more for endurance case. 

Independing from this I wanted to make my kernel partition bigger. Now just no time for this, we are still in developing with our device. 


>If not, we have to accept to loose some space for bad blocks, or use NOR :)
:) NOR is expensive. And UBI takes a lot of space since based on worst case estimation of NAND features. I have to find compromise

Thanks a lot for your support,
Sergey



-----Ursprüngliche Nachricht-----
Von: Richard Genoud [mailto:richard.genoud@gmail.com] 
Gesendet: Freitag, 1. März 2013 11:35
An: Velykokhatko, Sergey
Cc: Brian Norris; linux-mtd@lists.infradead.org; linux-kernel@vger.kernel.org; artem.bityutskiy@linux.intel.com
Betreff: Re: Bug in mtd_get_device_size()?

2013/3/1 Velykokhatko, Sergey <Sergey.Velykokhatko@mcc-med.de>:
> Hi Brian,
>
> Thanks for your answer. Ok, I have nothing against that my interpretation of mtd_get_device_size() purpose is wrong. But what you mean under: "Because your BEB_LIMIT=100, you are reserving 100*size/1024 (that is 9.8% of your total size, or 400 blocks) in *every* partition." Looks for me a little bit strange. Why? Because I expected that UBI reserves the place for bad block handling pool depending on the size of MTD partition (on that it running) and not on the size of the whole chip. Actually I have 2 partitions with UBI (for rootfs and for data) and without my patch UBI tries to reserve nearly 400 blocks on each (see down).
Reserving bad blocks depending on the size of the MTD partition is wrong, and here is why:
I didn't checked the datasheet of your nand chipset (actually, I didn't found it).
But let's say it's a standard one : your chip has 4096 blocks, and the manufacturer says that there won't be more than 80 bad blocks (20/1024)on the device during its ENDURANCE LIFE (endurance life means something like 100000 program/erase cylcles).
Those 80 bad blocks could appear *everywhere*, they won't be equally disposed on the device.
=> If you have a small bare MTD partition of 16blocks, and do a lot of write/erase cycles on it, we can imagine that there will be some bad blocks on it, and maybe all those 16 blocks will turn bad.
If UBI takes the size of MTD partition to compute the maximum number of bad erase blocks, for a 16blocks MTD partition, this would be
16*20/1024 =0.31 => there will be a lack of reserved erase blocks.
said differently: if you want to be sure to have 2MB space (16blocks) to write on, you have to reserve 80 blocks more. This is the worst case scenario.
>
> Why I set CONFIG_MTD_UBI_BEB_LIMIT to such high limit? Well, you are right: our NAND from production could contain up to 40 bad blocks. That is 1% of whole chip size. But our medical device should work in worst case each night for 10 years. I expect that in whole device life more blocks will be defect. Of course 10% for rootfs MTD is overkill since it will be updated very very seldom, but for data partititon 10% is probably even too low.
"I expect that in whole device life more blocks will be defect."
you have to double check that.
In all nand datasheets that I've seen, the given number was for the endurance life.
>From a Micron Nand datasheet :
Micron NAND devices are specified to have a minimum of 2,008 (NVB) valid blocks out of every 2,048 total available blocks. This means the devices may have blocks that are invalid when they are shipped. An invalid block is one that contains one or more bad bits. Additional bad blocks may develop with use. However, the total number of avail- able blocks will not fall below NVB during the endurance life of the product.

As there's very little information on how bad blocks appear, we can suppose that even on the 1st erase cycle of a block, it can turn bad.
That's why we have to use the worst case scenario.
>
>>That would reserve only 80 blocks on your system, and you would not see these warnings/errors, since you already have 115 blocks reserved.
> You mean *not on my system* but on each MTD running with UBI? :) Well 
> I was thinking to divide my UBI volumes on UBI1 in small sub MTDs. 
> Since I had 2 times cases, when I couldn't mount my ubi1:ubivol_data 
> (I don't know why it happened, probably because of bugs in pretty new 
> NAND driver from Atmel) and I should ubiformat/ubimkvolume for my MTD 
> with loosing of extreme important data on ubi1:ubivol_device. If I 
> really make new small MTDs for ubi1:ubivol_device/ ubi1:ubivol_config 
> with the actual kernel state they will be completely used with poll 
> for reserved bad blocks. No room for my data :)

yes, using a lot of UBI partition is not space friendly.
The optimized way is one UBI partition, and many ubi volumes...

By the way,  even your kernel_a partition can be seen as undersized (3MB). if your kernel is 2MB, there's only 1MB (8) left for eventual bad blocks.
I understands that it's "unlikely" that more than 8 bad blocks appears on a partition where you do not write very often, that this would be "bad luck", but who knows...
That will depend on the criticality of your device, "do we accept to may be brick one product out of xxxxx or not ?". If not, we have to accept to loose some space for bad blocks, or use NOR :)

Best regards,
Richard.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: Bug in mtd_get_device_size()?

[Ricard Wanderlof]

On Fri, 1 Mar 2013, Richard Genoud wrote:

> From a Micron Nand datasheet :
> Micron NAND devices are specified to have a minimum of 2,008 (NVB)
> valid blocks out
> of every 2,048 total available blocks. This means the devices may have
> blocks that are
> invalid when they are shipped. An invalid block is one that contains
> one or more bad
> bits. Additional bad blocks may develop with use. However, the total
> number of avail-
> able blocks will not fall below NVB during the endurance life of the product.
>
> As there's very little information on how bad blocks appear, we can
> suppose that even on the 1st erase cycle of a block, it can turn bad.
> That's why we have to use the worst case scenario.

I would think that the primary reason for blocks to go bad is that they 
wear out so that they don't meet the endurance specifications. I.e., when 
worn out, one or more bits will start to flip significantly sooner than on 
a non-worn-out block. Wearing out is a continual process; blocks don't 
just suddenly 'go bad'.

I suppose one can imagine catastrophic failures at any time as well. I 
have never seen this case being specifically reference in an application 
note or white paper from a flash manufacturer though. As you say the 
datasheets are not very forthcoming on that issue.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Bug in mtd_get_device_size()?

[Richard Genoud]

2013/3/1 Velykokhatko, Sergey <Sergey.Velykokhatko@mcc-med.de>:
> Hi Richard,
>
> Thanks a lot for your explanations. Now at least I understand your logic. And it seems to be reasonable. Your start point that all bad blocks for flash chip could be placed in single MTD. This is really worst worst case, but... Theoretically it could happened. And you should take care of it.
> And you are right again in things about my chip. I interpreted that up to 40 blocks could be bad from chip production. But now found on side 104 of 125 one note (sometimes I like datasheets :-) ):
>
> "
> Notes:
>  1. Invalid blocks are blocks that contain one or more bad bits. The device may contain bad
> blocks upon shipment. Additional bad blocks may develop over time; however, the total
> number of available blocks will not drop below NVB during the endurance life of the
> device. Do not erase or program blocks marked invalid by the factory.
> "
>
> Also I should expect up to 40 bad blocks. Nearly 1%.  No more for endurance case.
That less than many NAND device, so in your case, you should set
CONFIG_MTD_UBI_BEB_LIMIT to 10 (40 bad blocks on a total of 4096)

>
> Independing from this I wanted to make my kernel partition bigger. Now just no time for this, we are still in developing with our device.
>
>
>>If not, we have to accept to loose some space for bad blocks, or use NOR :)
> :) NOR is expensive. And UBI takes a lot of space since based on worst case estimation of NAND features. I have to find compromise
yes... may be one day we will have cheap, reliable and fast flash storage.
(and at least your nand is SLC, not MLC !)

And if you want to tweak the BEB_LIMIT for each of your UBI partition,
it's possible, via the ubiattach call ( get the master branchof of
git://git.infradead.org/mtd-utils.git )
cf http://git.infradead.org/mtd-utils.git/commit/878e06ea555ba5dbfb974b3904d1a86a9a0e20f5
and via the ubi module parameter :
mtd=<name|num|path>[,<vid_hdr_offs>[,max_beb_per1024]]

with that, you won't need your kernel patch anymore !

Regards,
Richard.

AW: Bug in mtd_get_device_size()?

[Velykokhatko, Sergey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4325 bytes --]

Hi Richard,

>And if you want to tweak the BEB_LIMIT for each of your UBI partition, it's possible, via the ubiattach call ( get the master branchof of git://git.infradead.org/mtd-utils.git ) cf http://git.infradead.org/mtd-utils.git/commit/878e06ea555ba5dbfb974b3904d1a86a9a0e20f5

Aha! I didn't see that before. In my case will be useful. Thanks for idea! 

Let I ask you one more question, probably you have better idea how to resolve it. If you have no other solution as my, should not answer. Also: as I mentioned before, I have one big partition with 4 UBI volumes on it: one of volumes will contain extreme important data (for example device type and serial number) and data on this volume will be written only several times for whole device life; and on other volume will be stored patient data that will be written relative often. Now in my SW that runs as init process I call ubiatach+mount. If ubiattach or mount for any of UBI volumes returns error, I call ubiformat+ubimkvol+mount again. This is normal use case when the device booted first time after production. With 2.6.38 and 3.3 kernel I had no problems but after update on 3.7 I got reported 2 cases when devices lost all their data. Unfortunately I have no additional information why it happened, but anyway is it really necessary to runs ubiformat+ubimkvol for such cases? Or is it possible to recover data? Since my solution for this case is to put the device data in separate MTD with one single UBI volume. But you know how much space I should reserve on NAND MTD for single XML-File with 200Bytes :-). Alternative is to try to mount only device volume, copy data in tmpfs, run ubiformat+ubimkvol+mount and copy the data back to the device volume. Or you have other idea?

Thanks a lot,
Best regards,
Sergey





-----Ursprüngliche Nachricht-----
Von: Richard Genoud [mailto:richard.genoud@gmail.com] 
Gesendet: Freitag, 1. März 2013 13:10
An: Velykokhatko, Sergey
Cc: Brian Norris; linux-mtd@lists.infradead.org; linux-kernel@vger.kernel.org; artem.bityutskiy@linux.intel.com
Betreff: Re: Bug in mtd_get_device_size()?

2013/3/1 Velykokhatko, Sergey <Sergey.Velykokhatko@mcc-med.de>:
> Hi Richard,
>
> Thanks a lot for your explanations. Now at least I understand your logic. And it seems to be reasonable. Your start point that all bad blocks for flash chip could be placed in single MTD. This is really worst worst case, but... Theoretically it could happened. And you should take care of it.
> And you are right again in things about my chip. I interpreted that up to 40 blocks could be bad from chip production. But now found on side 104 of 125 one note (sometimes I like datasheets :-) ):
>
> "
> Notes:
>  1. Invalid blocks are blocks that contain one or more bad bits. The 
> device may contain bad blocks upon shipment. Additional bad blocks may 
> develop over time; however, the total number of available blocks will 
> not drop below NVB during the endurance life of the device. Do not erase or program blocks marked invalid by the factory.
> "
>
> Also I should expect up to 40 bad blocks. Nearly 1%.  No more for endurance case.
That less than many NAND device, so in your case, you should set CONFIG_MTD_UBI_BEB_LIMIT to 10 (40 bad blocks on a total of 4096)

>
> Independing from this I wanted to make my kernel partition bigger. Now just no time for this, we are still in developing with our device.
>
>
>>If not, we have to accept to loose some space for bad blocks, or use 
>>NOR :)
> :) NOR is expensive. And UBI takes a lot of space since based on worst 
> case estimation of NAND features. I have to find compromise
yes... may be one day we will have cheap, reliable and fast flash storage.
(and at least your nand is SLC, not MLC !)

And if you want to tweak the BEB_LIMIT for each of your UBI partition, it's possible, via the ubiattach call ( get the master branchof of git://git.infradead.org/mtd-utils.git ) cf http://git.infradead.org/mtd-utils.git/commit/878e06ea555ba5dbfb974b3904d1a86a9a0e20f5
and via the ubi module parameter :
mtd=<name|num|path>[,<vid_hdr_offs>[,max_beb_per1024]]

with that, you won't need your kernel patch anymore !

Regards,
Richard.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: Bug in mtd_get_device_size()?

[Richard Genoud]

2013/3/1 Velykokhatko, Sergey <Sergey.Velykokhatko@mcc-med.de>:
> Hi Richard,
>
>>And if you want to tweak the BEB_LIMIT for each of your UBI partition, it's possible, via the ubiattach call ( get the master branchof of git://git.infradead.org/mtd-utils.git ) cf http://git.infradead.org/mtd-utils.git/commit/878e06ea555ba5dbfb974b3904d1a86a9a0e20f5
>
> Aha! I didn't see that before. In my case will be useful. Thanks for idea!
>
> Let I ask you one more question, probably you have better idea how to resolve it. If you have no other solution as my, should not answer. Also: as I mentioned before, I have one big partition with 4 UBI volumes on it: one of volumes will contain extreme important data (for example device type and serial number) and data on this volume will be written only several times for whole device life; and on other volume will be stored patient data that will be written relative often. Now in my SW that runs as init process I call ubiatach+mount. If ubiattach or mount for any of UBI volumes returns error, I call ubiformat+ubimkvol+mount again. This is normal use case when the device booted first time after production.
>With 2.6.38 and 3.3 kernel I had no problems but after update on 3.7 I got reported 2 cases when devices lost all their data.
Hum, that's clearly not normal.
> Unfortunately I have no additional information why it happened, but anyway is it really necessary to runs ubiformat+ubimkvol for such cases? Or is it possible to recover data?
I honestly don't know, but I'm sure Artem has some idea on that.
>Since my solution for this case is to put the device data in separate MTD with one single UBI volume. But you know how much space I should reserve on NAND MTD for single XML-File with 200Bytes :-).
I've got the same problem with uboot environment for example. It's
only some hundred bytes, and still I have to reserve the maximum bad
blocks number + 1 for the environment itself (so for your device 41).
I know, this looks overkill...
For 200bytes, I would try to store them elsewhere (spi dataflash,
eeprom...) if there's such devices on your board.
There's also the 1st block of the nand device which is guaranteed to
be "valid" for 1000 erase cycles (valid with 1-bit ECC per 528 bytes)

> Alternative is to try to mount only device volume, copy data in tmpfs, run ubiformat+ubimkvol+mount and copy the data back to the device volume. Or you have other idea?
>
> Thanks a lot,
> Best regards,
> Sergey
>

Best regards,
Richard.

Re: Bug in mtd_get_device_size()?

[Artem Bityutskiy]

On Fri, 2013-03-01 at 15:29 +0100, Richard Genoud wrote:
> > Unfortunately I have no additional information why it happened, but
> anyway is it really necessary to runs ubiformat+ubimkvol for such
> cases? Or is it possible to recover data?
> I honestly don't know, but I'm sure Artem has some idea on that.

Everything should work in theory. If there are issues, they should be
looked at and investigated. I do not have any better suggestion off the
top of my head.

> >Since my solution for this case is to put the device data in separate MTD with one single UBI volume. But you know how much space I should reserve on NAND MTD for single XML-File with 200Bytes :-).
> I've got the same problem with uboot environment for example. It's
> only some hundred bytes, and still I have to reserve the maximum bad
> blocks number + 1 for the environment itself (so for your device 41).
> I know, this looks overkill...
> For 200bytes, I would try to store them elsewhere (spi dataflash,
> eeprom...) if there's such devices on your board.
> There's also the 1st block of the nand device which is guaranteed to
> be "valid" for 1000 erase cycles (valid with 1-bit ECC per 528 bytes)

The ideal solution would be to not partition the chip at all, of course.

BTW, if we ara talking about a device for medicine with tens of years of
lifetime, you need to be careful about read disturb issues. In the MTD
web site we discuss them - and there is a suggestion to read whole UBI
device from time to time to force scrubbing.

> > Alternative is to try to mount only device volume, copy data in tmpfs, run ubiformat+ubimkvol+mount and copy the data back to the device volume. Or you have other idea?

Not sure why this would be needed. We did not do any on-flash format
breakage AFAIK. But I admit I did not read this thread carefully.

Sergey, feel free to ask specific questions in separate threads, to make
it easier to answer them.

-- 
Best Regards,
Artem Bityutskiy

UBI. How are critical these messages?

[Velykokhatko, Sergey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 25078 bytes --]

Hi Artem,

Thank you for your answer. I describe shortly what have I done for better understanding. We are using ubi for couple of years and with 2.6.38, 3.3 had no problems. In January 2013 I updated our developing state to 3.7 and in one week got two reports about loosing of device data. This problem could be cause by my software that tries to mount one by one ubi volumes on MTD5. If by any of these mounting an error happened, my SW runs ubiformat+ubimkvol+mount with loosing of whole device data. Till 3.7 this thing worked fine. Unfortunately I had no additional information what was wrong (I mean why mounting suddenly finished with error) and decided to run temporary klogd. Simultaneously updated to 3.8. In last time I heard nothing about of lost device data. Right now I read out kernel logs of 7 devices. In 2 devices I see strange "ecc unrecoverable error" messages. That messages appear only once in each of devices. I know that one of devices (mine) had 4 bad blocks in flash and it has 4 bad blocks now too. Could I ignore these messages, or not?

We are using atmel_nand driver with NAND_ECC_SOFT_BCH.

Best regards,
Sergey Velykokhatko





>From kernel log of device 1:

Mar  8 12:38:45 192 kern.notice kernel: [    9.906000] UBI: attaching mtd5 to ubi1
Mar  8 12:38:45 192 kern.err kernel: [   10.359000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   10.363000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1110:0, read only 64 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   10.374000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   10.378000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1110:0, read only 64 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   10.390000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   10.393000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1110:0, read only 64 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   10.405000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.err kernel: [   10.408000] UBI error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1110:0, read 64 bytes
Mar  8 12:38:45 192 kern.warn kernel: [   10.418000] Backtrace:
Mar  8 12:38:45 192 kern.warn kernel: [   10.421000] [<c000c614>] (dump_backtrace+0x0/0x114) from [<c0315e80>] (dump_stack+0x20/0x24)
Mar  8 12:38:45 192 kern.warn kernel: [   10.429000]  r6:c3ac2000 r5:00000040 r4:ffffffb6 r3:c0460e34
Mar  8 12:38:45 192 kern.warn kernel: [   10.435000] [<c0315e60>] (dump_stack+0x0/0x24) from [<c021042c>] (ubi_io_read+0x1e8/0x2b4)
Mar  8 12:38:45 192 kern.warn kernel: [   10.443000] [<c0210244>] (ubi_io_read+0x0/0x2b4) from [<c021077c>] (ubi_io_read_ec_hdr+0x7c/0x22c)
Mar  8 12:38:45 192 kern.warn kernel: [   10.452000] [<c0210700>] (ubi_io_read_ec_hdr+0x0/0x22c) from [<c0215330>] (ubi_attach+0x118/0x13c4)
Mar  8 12:38:45 192 kern.warn kernel: [   10.461000] [<c0215218>] (ubi_attach+0x0/0x13c4) from [<c020a8c0>] (ubi_attach_mtd_dev+0x5a8/0xbd8)
Mar  8 12:38:45 192 kern.warn kernel: [   10.470000] [<c020a318>] (ubi_attach_mtd_dev+0x0/0xbd8) from [<c020b18c>] (ctrl_cdev_ioctl+0xe0/0x194)
Mar  8 12:38:45 192 kern.warn kernel: [   10.479000] [<c020b0ac>] (ctrl_cdev_ioctl+0x0/0x194) from [<c00d5a40>] (vfs_ioctl+0x38/0x4c)
Mar  8 12:38:45 192 kern.warn kernel: [   10.488000]  r7:40186f40 r6:00000000 r5:c38880a0 r4:be880bd8
Mar  8 12:38:45 192 kern.warn kernel: [   10.494000] [<c00d5a08>] (vfs_ioctl+0x0/0x4c) from [<c00d6608>] (do_vfs_ioctl+0x55c/0x5c4)
Mar  8 12:38:45 192 kern.warn kernel: [   10.502000] [<c00d60ac>] (do_vfs_ioctl+0x0/0x5c4) from [<c00d66b8>] (sys_ioctl+0x48/0x70)
Mar  8 12:38:45 192 kern.warn kernel: [   10.510000] [<c00d6670>] (sys_ioctl+0x0/0x70) from [<c0009480>] (ret_fast_syscall+0x0/0x44)
Mar  8 12:38:45 192 kern.warn kernel: [   10.518000]  r8:c00096e4 r7:00000036 r6:0000c8e0 r5:be880bd8 r4:00000003
Mar  8 12:38:45 192 kern.err kernel: [   10.525000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   10.529000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 1110:512, read only 512 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   10.541000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   10.545000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 1110:512, read only 512 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   10.557000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   10.560000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 1110:512, read only 512 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   10.572000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.err kernel: [   10.576000] UBI error: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 1110:512, read 512 bytes
Mar  8 12:38:45 192 kern.warn kernel: [   10.586000] Backtrace:
Mar  8 12:38:45 192 kern.warn kernel: [   10.589000] [<c000c614>] (dump_backtrace+0x0/0x114) from [<c0315e80>] (dump_stack+0x20/0x24)
Mar  8 12:38:45 192 kern.warn kernel: [   10.597000]  r6:c3ac2000 r5:00000200 r4:ffffffb6 r3:c0460e34
Mar  8 12:38:45 192 kern.warn kernel: [   10.603000] [<c0315e60>] (dump_stack+0x0/0x24) from [<c021042c>] (ubi_io_read+0x1e8/0x2b4)
Mar  8 12:38:45 192 kern.warn kernel: [   10.611000] [<c0210244>] (ubi_io_read+0x0/0x2b4) from [<c02109ac>] (ubi_io_read_vid_hdr+0x80/0x240)
Mar  8 12:38:45 192 kern.warn kernel: [   10.620000] [<c021092c>] (ubi_io_read_vid_hdr+0x0/0x240) from [<c0215504>] (ubi_attach+0x2ec/0x13c4)
Mar  8 12:38:45 192 kern.warn kernel: [   10.629000] [<c0215218>] (ubi_attach+0x0/0x13c4) from [<c020a8c0>] (ubi_attach_mtd_dev+0x5a8/0xbd8)
Mar  8 12:38:45 192 kern.warn kernel: [   10.638000] [<c020a318>] (ubi_attach_mtd_dev+0x0/0xbd8) from [<c020b18c>] (ctrl_cdev_ioctl+0xe0/0x194)
Mar  8 12:38:45 192 kern.warn kernel: [   10.648000] [<c020b0ac>] (ctrl_cdev_ioctl+0x0/0x194) from [<c00d5a40>] (vfs_ioctl+0x38/0x4c)
Mar  8 12:38:45 192 kern.warn kernel: [   10.656000]  r7:40186f40 r6:00000000 r5:c38880a0 r4:be880bd8
Mar  8 12:38:45 192 kern.warn kernel: [   10.662000] [<c00d5a08>] (vfs_ioctl+0x0/0x4c) from [<c00d6608>] (do_vfs_ioctl+0x55c/0x5c4)
Mar  8 12:38:45 192 kern.warn kernel: [   10.670000] [<c00d60ac>] (do_vfs_ioctl+0x0/0x5c4) from [<c00d66b8>] (sys_ioctl+0x48/0x70)
Mar  8 12:38:45 192 kern.warn kernel: [   10.678000] [<c00d6670>] (sys_ioctl+0x0/0x70) from [<c0009480>] (ret_fast_syscall+0x0/0x44)
Mar  8 12:38:45 192 kern.warn kernel: [   10.686000]  r8:c00096e4 r7:00000036 r6:0000c8e0 r5:be880bd8 r4:00000003
Mar  8 12:38:45 192 kern.err kernel: [   10.696000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   10.699000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1116:0, read only 64 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   10.711000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   10.714000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1116:0, read only 64 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   10.726000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   10.730000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1116:0, read only 64 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   10.741000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.err kernel: [   10.745000] UBI error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1116:0, read 64 bytes
Mar  8 12:38:45 192 kern.warn kernel: [   10.755000] Backtrace:
Mar  8 12:38:45 192 kern.warn kernel: [   10.758000] [<c000c614>] (dump_backtrace+0x0/0x114) from [<c0315e80>] (dump_stack+0x20/0x24)
Mar  8 12:38:45 192 kern.warn kernel: [   10.766000]  r6:c3ac2000 r5:00000040 r4:ffffffb6 r3:c0460e34
Mar  8 12:38:45 192 kern.warn kernel: [   10.772000] [<c0315e60>] (dump_stack+0x0/0x24) from [<c021042c>] (ubi_io_read+0x1e8/0x2b4)
Mar  8 12:38:45 192 kern.warn kernel: [   10.780000] [<c0210244>] (ubi_io_read+0x0/0x2b4) from [<c021077c>] (ubi_io_read_ec_hdr+0x7c/0x22c)
Mar  8 12:38:45 192 kern.warn kernel: [   10.789000] [<c0210700>] (ubi_io_read_ec_hdr+0x0/0x22c) from [<c0215330>] (ubi_attach+0x118/0x13c4)
Mar  8 12:38:45 192 kern.warn kernel: [   10.798000] [<c0215218>] (ubi_attach+0x0/0x13c4) from [<c020a8c0>] (ubi_attach_mtd_dev+0x5a8/0xbd8)
Mar  8 12:38:45 192 kern.warn kernel: [   10.807000] [<c020a318>] (ubi_attach_mtd_dev+0x0/0xbd8) from [<c020b18c>] (ctrl_cdev_ioctl+0xe0/0x194)
Mar  8 12:38:45 192 kern.warn kernel: [   10.816000] [<c020b0ac>] (ctrl_cdev_ioctl+0x0/0x194) from [<c00d5a40>] (vfs_ioctl+0x38/0x4c)
Mar  8 12:38:45 192 kern.warn kernel: [   10.825000]  r7:40186f40 r6:00000000 r5:c38880a0 r4:be880bd8
Mar  8 12:38:45 192 kern.warn kernel: [   10.830000] [<c00d5a08>] (vfs_ioctl+0x0/0x4c) from [<c00d6608>] (do_vfs_ioctl+0x55c/0x5c4)
Mar  8 12:38:45 192 kern.warn kernel: [   10.839000] [<c00d60ac>] (do_vfs_ioctl+0x0/0x5c4) from [<c00d66b8>] (sys_ioctl+0x48/0x70)
Mar  8 12:38:45 192 kern.warn kernel: [   10.847000] [<c00d6670>] (sys_ioctl+0x0/0x70) from [<c0009480>] (ret_fast_syscall+0x0/0x44)
Mar  8 12:38:45 192 kern.warn kernel: [   10.855000]  r8:c00096e4 r7:00000036 r6:0000c8e0 r5:be880bd8 r4:00000003
Mar  8 12:38:45 192 kern.err kernel: [   10.862000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   10.866000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 1116:512, read only 512 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   10.878000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   10.881000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 1116:512, read only 512 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   10.894000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   10.897000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 1116:512, read only 512 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   10.909000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.err kernel: [   10.913000] UBI error: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 1116:512, read 512 bytes
Mar  8 12:38:45 192 kern.warn kernel: [   10.923000] Backtrace:
Mar  8 12:38:45 192 kern.warn kernel: [   10.926000] [<c000c614>] (dump_backtrace+0x0/0x114) from [<c0315e80>] (dump_stack+0x20/0x24)
Mar  8 12:38:45 192 kern.warn kernel: [   10.934000]  r6:c3ac2000 r5:00000200 r4:ffffffb6 r3:c0460e34
Mar  8 12:38:45 192 kern.warn kernel: [   10.940000] [<c0315e60>] (dump_stack+0x0/0x24) from [<c021042c>] (ubi_io_read+0x1e8/0x2b4)
Mar  8 12:38:45 192 kern.warn kernel: [   10.948000] [<c0210244>] (ubi_io_read+0x0/0x2b4) from [<c02109ac>] (ubi_io_read_vid_hdr+0x80/0x240)
Mar  8 12:38:45 192 kern.warn kernel: [   10.958000] [<c021092c>] (ubi_io_read_vid_hdr+0x0/0x240) from [<c0215504>] (ubi_attach+0x2ec/0x13c4)
Mar  8 12:38:45 192 kern.warn kernel: [   10.967000] [<c0215218>] (ubi_attach+0x0/0x13c4) from [<c020a8c0>] (ubi_attach_mtd_dev+0x5a8/0xbd8)
Mar  8 12:38:45 192 kern.warn kernel: [   10.976000] [<c020a318>] (ubi_attach_mtd_dev+0x0/0xbd8) from [<c020b18c>] (ctrl_cdev_ioctl+0xe0/0x194)
Mar  8 12:38:45 192 kern.warn kernel: [   10.985000] [<c020b0ac>] (ctrl_cdev_ioctl+0x0/0x194) from [<c00d5a40>] (vfs_ioctl+0x38/0x4c)
Mar  8 12:38:45 192 kern.warn kernel: [   10.994000]  r7:40186f40 r6:00000000 r5:c38880a0 r4:be880bd8
Mar  8 12:38:45 192 kern.warn kernel: [   10.999000] [<c00d5a08>] (vfs_ioctl+0x0/0x4c) from [<c00d6608>] (do_vfs_ioctl+0x55c/0x5c4)
Mar  8 12:38:45 192 kern.warn kernel: [   11.008000] [<c00d60ac>] (do_vfs_ioctl+0x0/0x5c4) from [<c00d66b8>] (sys_ioctl+0x48/0x70)
Mar  8 12:38:45 192 kern.warn kernel: [   11.016000] [<c00d6670>] (sys_ioctl+0x0/0x70) from [<c0009480>] (ret_fast_syscall+0x0/0x44)
Mar  8 12:38:45 192 kern.warn kernel: [   11.024000]  r8:c00096e4 r7:00000036 r6:0000c8e0 r5:be880bd8 r4:00000003
Mar  8 12:38:45 192 kern.err kernel: [   11.035000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   11.039000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1126:0, read only 64 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   11.050000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   11.054000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1126:0, read only 64 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   11.066000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   11.069000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1126:0, read only 64 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   11.081000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.err kernel: [   11.084000] UBI error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1126:0, read 64 bytes
Mar  8 12:38:45 192 kern.warn kernel: [   11.094000] Backtrace:
Mar  8 12:38:45 192 kern.warn kernel: [   11.097000] [<c000c614>] (dump_backtrace+0x0/0x114) from [<c0315e80>] (dump_stack+0x20/0x24)
Mar  8 12:38:45 192 kern.warn kernel: [   11.105000]  r6:c3ac2000 r5:00000040 r4:ffffffb6 r3:c0460e34
Mar  8 12:38:45 192 kern.warn kernel: [   11.111000] [<c0315e60>] (dump_stack+0x0/0x24) from [<c021042c>] (ubi_io_read+0x1e8/0x2b4)
Mar  8 12:38:45 192 kern.warn kernel: [   11.119000] [<c0210244>] (ubi_io_read+0x0/0x2b4) from [<c021077c>] (ubi_io_read_ec_hdr+0x7c/0x22c)
Mar  8 12:38:45 192 kern.warn kernel: [   11.128000] [<c0210700>] (ubi_io_read_ec_hdr+0x0/0x22c) from [<c0215330>] (ubi_attach+0x118/0x13c4)
Mar  8 12:38:45 192 kern.warn kernel: [   11.137000] [<c0215218>] (ubi_attach+0x0/0x13c4) from [<c020a8c0>] (ubi_attach_mtd_dev+0x5a8/0xbd8)
Mar  8 12:38:45 192 kern.warn kernel: [   11.146000] [<c020a318>] (ubi_attach_mtd_dev+0x0/0xbd8) from [<c020b18c>] (ctrl_cdev_ioctl+0xe0/0x194)
Mar  8 12:38:45 192 kern.warn kernel: [   11.156000] [<c020b0ac>] (ctrl_cdev_ioctl+0x0/0x194) from [<c00d5a40>] (vfs_ioctl+0x38/0x4c)
Mar  8 12:38:45 192 kern.warn kernel: [   11.164000]  r7:40186f40 r6:00000000 r5:c38880a0 r4:be880bd8
Mar  8 12:38:45 192 kern.warn kernel: [   11.170000] [<c00d5a08>] (vfs_ioctl+0x0/0x4c) from [<c00d6608>] (do_vfs_ioctl+0x55c/0x5c4)
Mar  8 12:38:45 192 kern.warn kernel: [   11.178000] [<c00d60ac>] (do_vfs_ioctl+0x0/0x5c4) from [<c00d66b8>] (sys_ioctl+0x48/0x70)
Mar  8 12:38:45 192 kern.warn kernel: [   11.186000] [<c00d6670>] (sys_ioctl+0x0/0x70) from [<c0009480>] (ret_fast_syscall+0x0/0x44)
Mar  8 12:38:45 192 kern.warn kernel: [   11.194000]  r8:c00096e4 r7:00000036 r6:0000c8e0 r5:be880bd8 r4:00000003
Mar  8 12:38:45 192 kern.err kernel: [   11.201000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   11.205000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 1126:512, read only 512 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   11.217000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   11.221000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 1126:512, read only 512 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   11.233000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.warn kernel: [   11.236000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 1126:512, read only 512 bytes, retry
Mar  8 12:38:45 192 kern.err kernel: [   11.248000] ecc unrecoverable error
Mar  8 12:38:45 192 kern.err kernel: [   11.252000] UBI error: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 1126:512, read 512 bytes
Mar  8 12:38:45 192 kern.warn kernel: [   11.262000] Backtrace:
Mar  8 12:38:45 192 kern.warn kernel: [   11.265000] [<c000c614>] (dump_backtrace+0x0/0x114) from [<c0315e80>] (dump_stack+0x20/0x24)
Mar  8 12:38:45 192 kern.warn kernel: [   11.273000]  r6:c3ac2000 r5:00000200 r4:ffffffb6 r3:c0460e34
Mar  8 12:38:45 192 kern.warn kernel: [   11.279000] [<c0315e60>] (dump_stack+0x0/0x24) from [<c021042c>] (ubi_io_read+0x1e8/0x2b4)
Mar  8 12:38:45 192 kern.warn kernel: [   11.287000] [<c0210244>] (ubi_io_read+0x0/0x2b4) from [<c02109ac>] (ubi_io_read_vid_hdr+0x80/0x240)
Mar  8 12:38:45 192 kern.warn kernel: [   11.296000] [<c021092c>] (ubi_io_read_vid_hdr+0x0/0x240) from [<c0215504>] (ubi_attach+0x2ec/0x13c4)
Mar  8 12:38:45 192 kern.warn kernel: [   11.305000] [<c0215218>] (ubi_attach+0x0/0x13c4) from [<c020a8c0>] (ubi_attach_mtd_dev+0x5a8/0xbd8)
Mar  8 12:38:45 192 kern.warn kernel: [   11.314000] [<c020a318>] (ubi_attach_mtd_dev+0x0/0xbd8) from [<c020b18c>] (ctrl_cdev_ioctl+0xe0/0x194)
Mar  8 12:38:45 192 kern.warn kernel: [   11.324000] [<c020b0ac>] (ctrl_cdev_ioctl+0x0/0x194) from [<c00d5a40>] (vfs_ioctl+0x38/0x4c)
Mar  8 12:38:45 192 kern.warn kernel: [   11.332000]  r7:40186f40 r6:00000000 r5:c38880a0 r4:be880bd8
Mar  8 12:38:45 192 kern.warn kernel: [   11.338000] [<c00d5a08>] (vfs_ioctl+0x0/0x4c) from [<c00d6608>] (do_vfs_ioctl+0x55c/0x5c4)
Mar  8 12:38:45 192 kern.warn kernel: [   11.346000] [<c00d60ac>] (do_vfs_ioctl+0x0/0x5c4) from [<c00d66b8>] (sys_ioctl+0x48/0x70)
Mar  8 12:38:45 192 kern.warn kernel: [   11.354000] [<c00d6670>] (sys_ioctl+0x0/0x70) from [<c0009480>] (ret_fast_syscall+0x0/0x44)
Mar  8 12:38:45 192 kern.warn kernel: [   11.362000]  r8:c00096e4 r7:00000036 r6:0000c8e0 r5:be880bd8 r4:00000003
Mar  8 12:38:45 192 kern.notice kernel: [   12.026000] UBI: scanning is finished
Mar  8 12:38:45 192 kern.notice kernel: [   12.066000] UBI: attached mtd5 (name "config_data", size 345 MiB) to ubi1
Mar  8 12:38:45 192 kern.notice kernel: [   12.073000] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
Mar  8 12:38:45 192 kern.notice kernel: [   12.080000] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
Mar  8 12:38:45 192 kern.notice kernel: [   12.087000] UBI: VID header offset: 512 (aligned 512), data offset: 2048
Mar  8 12:38:45 192 kern.notice kernel: [   12.094000] UBI: good PEBs: 2763, bad PEBs: 4, corrupted PEBs: 0
Mar  8 12:38:45 192 kern.notice kernel: [   12.100000] UBI: user volume: 4, internal volumes: 1, max. volumes count: 128



>From kernel log of device 2:

Mar  8 16:02:30 (none) kern.notice kernel: [    1.690000] UBI: attaching mtd5 to ubi1
Mar  8 16:02:30 (none) kern.err kernel: [    2.064000] ecc unrecoverable error
Mar  8 16:02:30 (none) kern.warn kernel: [    2.068000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 928:0, read only 64 bytes, retry
Mar  8 16:02:30 (none) kern.err kernel: [    2.068000] ecc unrecoverable error
Mar  8 16:02:30 (none) kern.warn kernel: [    2.072000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 928:0, read only 64 bytes, retry
Mar  8 16:02:30 (none) kern.err kernel: [    2.072000] ecc unrecoverable error
Mar  8 16:02:30 (none) kern.warn kernel: [    2.076000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 928:0, read only 64 bytes, retry
Mar  8 16:02:30 (none) kern.err kernel: [    2.076000] ecc unrecoverable error
Mar  8 16:02:30 (none) kern.err kernel: [    2.080000] UBI error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 928:0, read 64 bytes
Mar  8 16:02:30 (none) kern.warn kernel: [    2.090000] Backtrace:
Mar  8 16:02:30 (none) kern.warn kernel: [    2.090000] [<c000c614>] (dump_backtrace+0x0/0x114) from [<c0315e80>] (dump_stack+0x20/0x24)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.090000]  r6:c3a84000 r5:00000040 r4:ffffffb6 r3:c0460e34
Mar  8 16:02:30 (none) kern.warn kernel: [    2.090000] [<c0315e60>] (dump_stack+0x0/0x24) from [<c021042c>] (ubi_io_read+0x1e8/0x2b4)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.090000] [<c0210244>] (ubi_io_read+0x0/0x2b4) from [<c021077c>] (ubi_io_read_ec_hdr+0x7c/0x22c)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.090000] [<c0210700>] (ubi_io_read_ec_hdr+0x0/0x22c) from [<c0215330>] (ubi_attach+0x118/0x13c4)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.090000] [<c0215218>] (ubi_attach+0x0/0x13c4) from [<c020a8c0>] (ubi_attach_mtd_dev+0x5a8/0xbd8)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.091000] [<c020a318>] (ubi_attach_mtd_dev+0x0/0xbd8) from [<c020b18c>] (ctrl_cdev_ioctl+0xe0/0x194)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.091000] [<c020b0ac>] (ctrl_cdev_ioctl+0x0/0x194) from [<c00d5a40>] (vfs_ioctl+0x38/0x4c)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.091000]  r7:40186f40 r6:00000000 r5:c3888d20 r4:bec84bd8
Mar  8 16:02:30 (none) kern.warn kernel: [    2.091000] [<c00d5a08>] (vfs_ioctl+0x0/0x4c) from [<c00d6608>] (do_vfs_ioctl+0x55c/0x5c4)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.091000] [<c00d60ac>] (do_vfs_ioctl+0x0/0x5c4) from [<c00d66b8>] (sys_ioctl+0x48/0x70)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.091000] [<c00d6670>] (sys_ioctl+0x0/0x70) from [<c0009480>] (ret_fast_syscall+0x0/0x44)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.091000]  r8:c00096e4 r7:00000036 r6:0000c8e0 r5:bec84bd8 r4:00000003
Mar  8 16:02:30 (none) kern.err kernel: [    2.092000] ecc unrecoverable error
Mar  8 16:02:30 (none) kern.warn kernel: [    2.095000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 928:512, read only 512 bytes, retry
Mar  8 16:02:30 (none) kern.err kernel: [    2.096000] ecc unrecoverable error
Mar  8 16:02:30 (none) kern.warn kernel: [    2.099000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 928:512, read only 512 bytes, retry
Mar  8 16:02:30 (none) kern.err kernel: [    2.100000] ecc unrecoverable error
Mar  8 16:02:30 (none) kern.warn kernel: [    2.103000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 928:512, read only 512 bytes, retry
Mar  8 16:02:30 (none) kern.err kernel: [    2.104000] ecc unrecoverable error
Mar  8 16:02:30 (none) kern.err kernel: [    2.107000] UBI error: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 928:512, read 512 bytes
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000] Backtrace:
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000] [<c000c614>] (dump_backtrace+0x0/0x114) from [<c0315e80>] (dump_stack+0x20/0x24)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000]  r6:c3a84000 r5:00000200 r4:ffffffb6 r3:c0460e34
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000] [<c0315e60>] (dump_stack+0x0/0x24) from [<c021042c>] (ubi_io_read+0x1e8/0x2b4)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000] [<c0210244>] (ubi_io_read+0x0/0x2b4) from [<c02109ac>] (ubi_io_read_vid_hdr+0x80/0x240)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000] [<c021092c>] (ubi_io_read_vid_hdr+0x0/0x240) from [<c0215504>] (ubi_attach+0x2ec/0x13c4)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000] [<c0215218>] (ubi_attach+0x0/0x13c4) from [<c020a8c0>] (ubi_attach_mtd_dev+0x5a8/0xbd8)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000] [<c020a318>] (ubi_attach_mtd_dev+0x0/0xbd8) from [<c020b18c>] (ctrl_cdev_ioctl+0xe0/0x194)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000] [<c020b0ac>] (ctrl_cdev_ioctl+0x0/0x194) from [<c00d5a40>] (vfs_ioctl+0x38/0x4c)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000]  r7:40186f40 r6:00000000 r5:c3888d20 r4:bec84bd8
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000] [<c00d5a08>] (vfs_ioctl+0x0/0x4c) from [<c00d6608>] (do_vfs_ioctl+0x55c/0x5c4)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000] [<c00d60ac>] (do_vfs_ioctl+0x0/0x5c4) from [<c00d66b8>] (sys_ioctl+0x48/0x70)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000] [<c00d6670>] (sys_ioctl+0x0/0x70) from [<c0009480>] (ret_fast_syscall+0x0/0x44)
Mar  8 16:02:30 (none) kern.warn kernel: [    2.118000]  r8:c00096e4 r7:00000036 r6:0000c8e0 r5:bec84bd8 r4:00000003
Mar  8 16:02:30 (none) kern.notice kernel: [    2.857000] UBI: scanning is finished
Mar  8 16:02:30 (none) kern.notice kernel: [    2.889000] UBI: attached mtd5 (name "config_data", size 345 MiB) to ubi1
Mar  8 16:02:30 (none) kern.notice kernel: [    2.890000] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
Mar  8 16:02:30 (none) kern.notice kernel: [    2.890000] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
Mar  8 16:02:30 (none) kern.notice kernel: [    2.890000] UBI: VID header offset: 512 (aligned 512), data offset: 2048
Mar  8 16:02:30 (none) kern.notice kernel: [    2.890000] UBI: good PEBs: 2763, bad PEBs: 4, corrupted PEBs: 0
Mar  8 16:02:30 (none) kern.notice kernel: [    2.890000] UBI: user volume: 4, internal volumes: 1, max. volumes count: 128
Mar  8 16:02:30 (none) kern.notice kernel: [    2.890000] UBI: max/mean erase counter: 95/39, WL threshold: 4096, image sequence number: 2041614926
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: UBI. How are critical these messages?

[Artem Bityutskiy]

On Mon, 2013-03-11 at 17:13 +0100, Velykokhatko, Sergey wrote:
> Mar  8 12:38:45 192 kern.notice kernel: [    9.906000] UBI: attaching mtd5 to ubi1
> Mar  8 12:38:45 192 kern.err kernel: [   10.359000] ecc unrecoverable error
> Mar  8 12:38:45 192 kern.warn kernel: [   10.363000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1110:0, read only 64 bytes, retry
> Mar  8 12:38:45 192 kern.err kernel: [   10.374000] ecc unrecoverable error
> Mar  8 12:38:45 192 kern.warn kernel: [   10.378000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1110:0, read only 64 bytes, retry
> Mar  8 12:38:45 192 kern.err kernel: [   10.390000] ecc unrecoverable error
> Mar  8 12:38:45 192 kern.warn kernel: [   10.393000] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1110:0, read only 64 bytes, retry
> Mar  8 12:38:45 192 kern.err kernel: [   10.405000] ecc unrecoverable error
> Mar  8 12:38:45 192 kern.err kernel: [   10.408000] UBI error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 1110:0, read 64 bytes
> Mar  8 12:38:45 192 kern.warn kernel: [   10.418000] Backtrace:
> Mar  8 12:38:45 192 kern.warn kernel: [   10.421000] [<c000c614>] (dump_backtrace+0x0/0x114) from [<c0315e80>] (dump_stack+0x20/0x24)
> Mar  8 12:38:45 192 kern.warn kernel: [   10.429000]  r6:c3ac2000 r5:00000040 r4:ffffffb6 r3:c0460e34
> Mar  8 12:38:45 192 kern.warn kernel: [   10.435000] [<c0315e60>] (dump_stack+0x0/0x24) from [<c021042c>] (ubi_io_read+0x1e8/0x2b4)
> Mar  8 12:38:45 192 kern.warn kernel: [   10.443000] [<c0210244>] (ubi_io_read+0x0/0x2b4) from [<c021077c>] (ubi_io_read_ec_hdr+0x7c/0x22c)
> Mar  8 12:38:45 192 kern.warn kernel: [   10.452000] [<c0210700>] (ubi_io_read_ec_hdr+0x0/0x22c) from [<c0215330>] (ubi_attach+0x118/0x13c4)
> Mar  8 12:38:45 192 kern.warn kernel: [   10.461000] [<c0215218>] (ubi_attach+0x0/0x13c4) from [<c020a8c0>] (ubi_attach_mtd_dev+0x5a8/0xbd8)
> Mar  8 12:38:45 192 kern.warn kernel: [   10.470000] [<c020a318>] (ubi_attach_mtd_dev+0x0/0xbd8) from [<c020b18c>] (ctrl_cdev_ioctl+0xe0/0x194)
> Mar  8 12:38:45 192 kern.warn kernel: [   10.479000] [<c020b0ac>] (ctrl_cdev_ioctl+0x0/0x194) from [<c00d5a40>] (vfs_ioctl+0x38/0x4c)
> Mar  8 12:38:45 192 kern.warn kernel: [   10.488000]  r7:40186f40 r6:00000000 r5:c38880a0 r4:be880bd8
> Mar  8 12:38:45 192 kern.warn kernel: [   10.494000] [<c00d5a08>] (vfs_ioctl+0x0/0x4c) from [<c00d6608>] (do_vfs_ioctl+0x55c/0x5c4)
> Mar  8 12:38:45 192 kern.warn kernel: [   10.502000] [<c00d60ac>] (do_vfs_ioctl+0x0/0x5c4) from [<c00d66b8>] (sys_ioctl+0x48/0x70)
> Mar  8 12:38:45 192 kern.warn kernel: [   10.510000] [<c00d6670>] (sys_ioctl+0x0/0x70) from [<c0009480>] (ret_fast_syscall+0x0/0x44)
> Mar  8 12:38:45 192 kern.warn kernel: [   10.518000]  r8:c00096e4 r7:00000036 r6:0000c8e0 r5:be880bd8 r4:00000003

These look like a broken driver, not an UBI/UBIFS problem. Try to run
MTD tests and validate your driver in the modern kernel first. The MTD
tests are kernel module, they work by insmoding. You should find some
info on the MTD website.

-- 
Best Regards,
Artem Bityutskiy