1. 02 6月, 2009 2 次提交
    • D
      UBI: add notification API · 0e0ee1cc
      Dmitry Pervushin 提交于
      UBI volume notifications are intended to create the API to get clients
      notified about volume creation/deletion, renaming and re-sizing. A
      client can subscribe to these notifications using 'ubi_volume_register()'
      and cancel the subscription using 'ubi_volume_unregister()'. When UBI
      volumes change, a blocking notifier is called. Clients also can request
      "added" events on all volumes that existed before client subscribed
      to the notifications.
      
      If we use notifications instead of calling functions like 'ubi_gluebi_xxx()',
      we can make the MTD emulation layer to be more flexible: build it as a
      separate module and load/unload it on demand.
      
      [Artem: many cleanups, rework locking, add "updated" event, provide
       device/volume info in notifiers]
      Signed-off-by: NDmitry Pervushin <dpervushin@embeddedalley.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      0e0ee1cc
    • A
      UBI: do not switch to R/O mode on read errors · b86a2c56
      Artem Bityutskiy 提交于
      This patch improves UBI errors handling. ATM UBI switches to
      R/O mode when the WL worker fails to read the source PEB.
      This means that the upper layers (e.g., UBIFS) has no
      chances to unmap the erroneous PEB and fix the error.
      This patch changes this behaviour and makes UBI put PEBs
      like this into a separate RB-tree, thus preventing the
      WL worker from hitting the same read errors again and
      again.
      
      But there is a 10% limit on a maximum amount of PEBs like this.
      If there are too much of them, UBI switches to R/O mode.
      
      Additionally, this patch teaches UBI not to panic and
      switch to R/O mode if after a PEB has been copied, the
      target LEB cannot be read back. Instead, now UBI cancels
      the operation and schedules the target PEB for torturing.
      
      The error paths has been tested by ingecting errors
      into 'ubi_eba_copy_leb()'.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      b86a2c56
  2. 26 5月, 2009 1 次提交
    • A
      UBI: fix race condition · ddbd3b61
      Artem Bityutskiy 提交于
      This patch fixes a minor problem where we may fail to wake
      upe the UBI background thread. This is not fatal at all,
      it may just result at sligtly worse performace for a short
      period of time, just because the thread will be woken up
      when real I/O on the UBI starts.
      
      Anywey, the issue is the race condition between
      'ubi_attach_mtd_dev()' and 'ubi_thread()'. If we do not
      serialize them, the 'wake_up_process()' call may be done
      before 'ubi_thread()' went seep, but after it checked
      'ubi->thread_enabled'.
      
      This issue was spotted by Shin Hong <hongshin@gmail.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      ddbd3b61
  3. 18 5月, 2009 3 次提交
  4. 21 1月, 2009 2 次提交
  5. 07 1月, 2009 1 次提交
  6. 23 12月, 2008 1 次提交
  7. 10 12月, 2008 2 次提交
  8. 25 7月, 2008 1 次提交
    • A
      UBI: always start the background thread · d37e6bf6
      Artem Bityutskiy 提交于
      This fix only affects UBI debugging.
      
      If the the background thread is disabled for debugging purposes,
      start it anyway, because otherwise we see tonns of kernel debugging
      complaints like this:
      
      INFO: task ubi_bgt0d:26857 blocked for more than 120 seconds.
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      ubi_bgt0d     D dd37bf94     0 26857      2
             dd37bfcc 00000086 f8e17cea dd37bf94 00000046 00000000 00000000 f5c62430
             f5c62430 f5c62590 c2a09c80 f6cbd498 dd8e9cbc 00000296 dd37bfb0 00000296
             dd8e9cb8 dd8e9cbc dd37bfcc c0119774 00000000 00000000 c0132e89 f6961560
      Call Trace:
       [<f8e17cea>] ? ubi_thread+0x0/0x127 [ubi]
       [<c0119774>] ? complete+0x43/0x4b
       [<c0132e89>] ? kthread+0x0/0x5b
       [<f8e17cea>] ? ubi_thread+0x0/0x127 [ubi]
       [<c0132eae>] kthread+0x25/0x5b
       [<c0132e89>] ? kthread+0x0/0x5b
       [<c0104953>] kernel_thread_helper+0x7/0x14
       =======================
      
      So start it, and go sleep inside it, instead of creating it and never
      start.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      d37e6bf6
  9. 24 7月, 2008 9 次提交
  10. 23 4月, 2008 1 次提交
  11. 20 4月, 2008 1 次提交
  12. 17 4月, 2008 1 次提交
  13. 04 3月, 2008 1 次提交
  14. 25 1月, 2008 4 次提交
    • A
      UBI: bugfix: calculate data offset properly · d5360587
      Artem Bityutskiy 提交于
      Data offset is VID header offset + VID header size aligned to
      the min. I/O unit size up.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      d5360587
    • A
      UBI: amend array size · ddc49391
      Artem Bityutskiy 提交于
      Since the data offset parameter was removed, the size of
      the parameters array is now 2, not 3.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      ddc49391
    • A
      UBI: add auto-resize feature · 4ccf8cff
      Artem Bityutskiy 提交于
      The problem: NAND flashes have different amount of initial bad physical
      eraseblocks (marked as bad by the manufacturer). For example, for 256MiB
      Samsung OneNAND flash there might be from 0 to 40 bad initial eraseblocks,
      which is about 2%. When UBI is used as the base system, one needs to know
      the exact amount of good physical eraseblocks, because this number is
      needed to create the UBI image which is put to the devices during
      production. But this number is not know, which forces us to use the
      minimum number of good physical eraseblocks. And UBI additionally
      reserves some percentage of physical eraseblocks for bad block handling
      (default is 1%), so we have 1-3% of PEBs reserved at the end, depending
      on the amount of initial bad PEBs. But it is desired to always have
      1% (or more, depending on the configuration).
      
      Solution: this patch adds an "auto-resize" flag to the volume table.
      The volume which has the "auto-resize" flag will automatically be re-sized
      (enlarged) on the first UBI initialization. UBI clears the flag when
      the volume is re-sized. Only one volume may have the "auto-resize" flag.
      
      So, the production UBI image may have one volume with "auto-resize"
      flag set, and its size is automatically adjusted on the first boot
      of the device.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      4ccf8cff
    • A
      UBI: get rid of ubi_ltree_slab · b9a06623
      Artem Bityutskiy 提交于
      This slab cache is not really needed since the number of objects
      is low and the constructor does not make much sense because we
      allocate oblects when doint I/O, which is way slower then allocation.
      Suggested-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      b9a06623
  15. 27 12月, 2007 10 次提交