* Re: Bug in mtd_get_device_size()? [not found] <BAF0C2081321BA469F9ADF648F97D9B04C78FA6069@MCC023.weinmann.com> @ 2013-02-28 17:24 ` Brian Norris 2013-03-01 8:10 ` Richard Genoud 2013-03-01 8:29 ` Velykokhatko, Sergey 0 siblings, 2 replies; 13+ messages in thread From: Brian Norris @ 2013-02-28 17:24 UTC (permalink / raw) To: Velykokhatko, Sergey Cc: linux-mtd, linux-kernel, artem.bityutskiy, Richard Genoud + 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bug in mtd_get_device_size()? 2013-02-28 17:24 ` Bug in mtd_get_device_size()? Brian Norris @ 2013-03-01 8:10 ` Richard Genoud 2013-03-01 9:36 ` AW: " Velykokhatko, Sergey 2013-03-01 8:29 ` Velykokhatko, Sergey 1 sibling, 1 reply; 13+ messages in thread From: Richard Genoud @ 2013-03-01 8:10 UTC (permalink / raw) To: Brian Norris Cc: Velykokhatko, Sergey, linux-mtd, linux-kernel, artem.bityutskiy 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 ? ^ permalink raw reply [flat|nested] 13+ messages in thread
* AW: Bug in mtd_get_device_size()? 2013-03-01 8:10 ` Richard Genoud @ 2013-03-01 9:36 ` Velykokhatko, Sergey 0 siblings, 0 replies; 13+ messages in thread From: Velykokhatko, Sergey @ 2013-03-01 9:36 UTC (permalink / raw) To: 'Richard Genoud', Brian Norris Cc: linux-mtd, linux-kernel, artem.bityutskiy [-- 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¥ ^ permalink raw reply [flat|nested] 13+ messages in thread
* AW: Bug in mtd_get_device_size()? 2013-02-28 17:24 ` Bug in mtd_get_device_size()? Brian Norris 2013-03-01 8:10 ` Richard Genoud @ 2013-03-01 8:29 ` Velykokhatko, Sergey 2013-03-01 10:35 ` Richard Genoud 1 sibling, 1 reply; 13+ messages in thread From: Velykokhatko, Sergey @ 2013-03-01 8:29 UTC (permalink / raw) To: 'Brian Norris' Cc: linux-mtd, linux-kernel, artem.bityutskiy, Richard Genoud 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bug in mtd_get_device_size()? 2013-03-01 8:29 ` Velykokhatko, Sergey @ 2013-03-01 10:35 ` Richard Genoud 2013-03-01 11:49 ` AW: " Velykokhatko, Sergey 2013-03-01 12:02 ` Bug in mtd_get_device_size()? Ricard Wanderlof 0 siblings, 2 replies; 13+ messages in thread From: Richard Genoud @ 2013-03-01 10:35 UTC (permalink / raw) To: Velykokhatko, Sergey Cc: Brian Norris, linux-mtd, linux-kernel, artem.bityutskiy 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* AW: Bug in mtd_get_device_size()? 2013-03-01 10:35 ` Richard Genoud @ 2013-03-01 11:49 ` Velykokhatko, Sergey 2013-03-01 12:09 ` Richard Genoud 2013-03-01 12:02 ` Bug in mtd_get_device_size()? Ricard Wanderlof 1 sibling, 1 reply; 13+ messages in thread From: Velykokhatko, Sergey @ 2013-03-01 11:49 UTC (permalink / raw) To: 'Richard Genoud' Cc: Brian Norris, linux-mtd, linux-kernel, artem.bityutskiy [-- 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¥ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bug in mtd_get_device_size()? 2013-03-01 11:49 ` AW: " Velykokhatko, Sergey @ 2013-03-01 12:09 ` Richard Genoud 2013-03-01 13:27 ` AW: " Velykokhatko, Sergey 0 siblings, 1 reply; 13+ messages in thread From: Richard Genoud @ 2013-03-01 12:09 UTC (permalink / raw) To: Velykokhatko, Sergey Cc: Brian Norris, linux-mtd, linux-kernel, artem.bityutskiy 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* AW: Bug in mtd_get_device_size()? 2013-03-01 12:09 ` Richard Genoud @ 2013-03-01 13:27 ` Velykokhatko, Sergey 2013-03-01 14:29 ` Richard Genoud 0 siblings, 1 reply; 13+ messages in thread From: Velykokhatko, Sergey @ 2013-03-01 13:27 UTC (permalink / raw) To: 'Richard Genoud' Cc: Brian Norris, linux-mtd, linux-kernel, artem.bityutskiy [-- 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¥ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bug in mtd_get_device_size()? 2013-03-01 13:27 ` AW: " Velykokhatko, Sergey @ 2013-03-01 14:29 ` Richard Genoud 2013-03-11 8:08 ` Artem Bityutskiy 0 siblings, 1 reply; 13+ messages in thread From: Richard Genoud @ 2013-03-01 14:29 UTC (permalink / raw) To: Velykokhatko, Sergey Cc: Brian Norris, linux-mtd, linux-kernel, artem.bityutskiy, Ricard Wanderlof 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bug in mtd_get_device_size()? 2013-03-01 14:29 ` Richard Genoud @ 2013-03-11 8:08 ` Artem Bityutskiy 2013-03-11 16:13 ` UBI. How are critical these messages? Velykokhatko, Sergey 0 siblings, 1 reply; 13+ messages in thread From: Artem Bityutskiy @ 2013-03-11 8:08 UTC (permalink / raw) To: Richard Genoud, Velykokhatko, Sergey Cc: Brian Norris, linux-mtd, linux-kernel, Ricard Wanderlof 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* UBI. How are critical these messages? 2013-03-11 8:08 ` Artem Bityutskiy @ 2013-03-11 16:13 ` Velykokhatko, Sergey 2013-03-11 16:39 ` Artem Bityutskiy 0 siblings, 1 reply; 13+ messages in thread From: Velykokhatko, Sergey @ 2013-03-11 16:13 UTC (permalink / raw) To: 'artem.bityutskiy@linux.intel.com', Richard Genoud Cc: Brian Norris, linux-mtd, linux-kernel, Ricard Wanderlof [-- 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¥ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: UBI. How are critical these messages? 2013-03-11 16:13 ` UBI. How are critical these messages? Velykokhatko, Sergey @ 2013-03-11 16:39 ` Artem Bityutskiy 0 siblings, 0 replies; 13+ messages in thread From: Artem Bityutskiy @ 2013-03-11 16:39 UTC (permalink / raw) To: Velykokhatko, Sergey Cc: Richard Genoud, Brian Norris, linux-mtd, linux-kernel, Ricard Wanderlof 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bug in mtd_get_device_size()? 2013-03-01 10:35 ` Richard Genoud 2013-03-01 11:49 ` AW: " Velykokhatko, Sergey @ 2013-03-01 12:02 ` Ricard Wanderlof 1 sibling, 0 replies; 13+ messages in thread From: Ricard Wanderlof @ 2013-03-01 12:02 UTC (permalink / raw) To: Richard Genoud Cc: Velykokhatko, Sergey, artem.bityutskiy, Brian Norris, linux-mtd, linux-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-03-11 16:38 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <BAF0C2081321BA469F9ADF648F97D9B04C78FA6069@MCC023.weinmann.com>
2013-02-28 17:24 ` Bug in mtd_get_device_size()? Brian Norris
2013-03-01 8:10 ` Richard Genoud
2013-03-01 9:36 ` AW: " Velykokhatko, Sergey
2013-03-01 8:29 ` Velykokhatko, Sergey
2013-03-01 10:35 ` Richard Genoud
2013-03-01 11:49 ` AW: " Velykokhatko, Sergey
2013-03-01 12:09 ` Richard Genoud
2013-03-01 13:27 ` AW: " Velykokhatko, Sergey
2013-03-01 14:29 ` Richard Genoud
2013-03-11 8:08 ` Artem Bityutskiy
2013-03-11 16:13 ` UBI. How are critical these messages? Velykokhatko, Sergey
2013-03-11 16:39 ` Artem Bityutskiy
2013-03-01 12:02 ` Bug in mtd_get_device_size()? Ricard Wanderlof
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).