1. 03 12月, 2012 1 次提交
  2. 03 10月, 2012 2 次提交
  3. 26 9月, 2012 1 次提交
  4. 04 9月, 2012 12 次提交
  5. 21 5月, 2012 8 次提交
  6. 09 3月, 2012 2 次提交
  7. 10 1月, 2012 1 次提交
  8. 01 6月, 2011 2 次提交
    • A
      UBI: fix oops in error path · 01a4110d
      Artem Bityutskiy 提交于
      This patch fixes an oops in the error path of 'ubi_attach_mtd_dev()'. If
      anything after 'uif_init()' fails, we get an oops in 'cancel_pending()'. The
      reason is that 'uif_close()' drops the last reference count for 'ubi->dev' and
      whole 'struct ubi_device' is freed. And then
      'ubi_wl_close()'->'cancel_pending()' tries to access the 'ubi' pointer and
      problems begin.
      
      Note, in 'ubi_detach_mtd_dev()' function we get a device reference to
      work-around this issue. Do the same in the error path of
      'ubi_attach_mtd_dev()'.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      01a4110d
    • A
      UBI: use debugfs for the extra checks knobs · 2a734bb8
      Artem Bityutskiy 提交于
      This patch introduces debugfs support to UBI. All the UBI stuff is kept in the
      "ubi" debugfs directory, which contains per-UBI device "ubi/ubiX"
      sub-directories, containing debugging files. This file also creates
      "ubi/ubiX/chk_gen" and "ubi/ubiX/chk_io" knobs for switching general and I/O
      extra checks on and off. And it removes the 'debug_chks' UBI module parameters.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      2a734bb8
  9. 16 3月, 2011 2 次提交
    • A
      UBI: make tests modes dynamic · 28237e45
      Artem Bityutskiy 提交于
      Similarly to the debugging checks and message, make the test modes
      be dynamically selected via the "debug_tsts" module parameter or
      via the "/sys/module/ubi/parameters/debug_tsts" sysfs file. This
      is consistent with UBIFS as well.
      
      And now, since all the Kconfig knobs became dynamic, we can remove
      the Kconfig.debug file completely.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      28237e45
    • A
      UBI: kill debugging buffer · 6edb9793
      Artem Bityutskiy 提交于
      This patch kills the 'ubi->dbg_peb_buf' debugging buffer and the
      associated mutex, because all users of this buffer are now gone.
      We are killing this buffer because we are going to switch to
      dynamic debugging control, just like in UBIFS, which means that
      CONFIG_MTD_UBI_DEBUG_PARANOID will be removed. In this case we'd
      end up always allocating 'ubi->dbg_peb_buf', which is rather large
      (128KiB or more), and this would be wasteful. Thus, we are just
      killing it.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      6edb9793
  10. 08 3月, 2011 1 次提交
  11. 07 2月, 2011 1 次提交
  12. 30 1月, 2011 1 次提交
  13. 26 1月, 2011 1 次提交
  14. 06 1月, 2011 1 次提交
  15. 19 10月, 2010 2 次提交
    • A
      UBI: preserve corrupted PEBs · 5fc01ab6
      Artem Bityutskiy 提交于
      Currently UBI erases all corrupted eraseblocks, irrespectively of the nature
      of corruption: corruption due to power cuts and non-power cut corruption.
      The former case is OK, but the latter is not, because UBI may destroy
      potentially important data.
      
      With this patch, during scanning, when UBI hits a PEB with corrupted VID
      header, it checks whether this PEB contains only 0xFF data. If yes, it is
      safe to erase this PEB and it is put to the 'erase' list. If not, this may
      be important data and it is better to avoid erasing this PEB. Instead,
      UBI puts it to the corr list and moves out of the pool of available PEB.
      IOW, UBI preserves this PEB.
      
      Such corrupted PEB lessen the amount of available PEBs. So the more of them
      we accumulate, the less PEBs are available. The maximum amount of non-power
      cut corrupted PEBs is 8.
      
      This patch is a response to UBIFS problem where reporter
      (Matthew L. Creech <mlcreech@gmail.com>) observes that UBIFS index points
      to an unmapped LEB. The theory is that corresponding PEB somehow got
      corrupted and UBI wiped it. This patch (actually a series of patches)
      tries to make sure such PEBs are preserved - this would make it is easier
      to analyze the corruption.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      5fc01ab6
    • A
      UBI: fix small 80 characters limit style issue · c174a08c
      Artem Bityutskiy 提交于
      One line was longer than 80 lines, make it shorter.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      c174a08c
  16. 02 8月, 2010 1 次提交
    • A
      UBI: do not warn unnecessarily · 64d4b4c9
      Artem Bityutskiy 提交于
      Currently, when UBI attaches an MTD device and cannot reserve all 1% (by
      default) of PEBs for bad eraseblocks handling, it prints a warning. However,
      Matthew L. Creech <mlcreech@gmail.com> is not very happy to see this warning,
      because he did reserve enough of PEB at the beginning, but with time some
      PEBs became bad. The warning is not necessary in this case.
      
      This patch makes UBI print the warning
       o if this is a new image
       o of this is used image and the amount of reserved PEBs is only 10% (or less)
         of the size of the reserved PEB pool.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      64d4b4c9
  17. 06 5月, 2010 1 次提交
    • M
      UBI: init even if MTD device cannot be attached, if built into kernel · af7ad7a0
      Marc Kleine-Budde 提交于
      UBI can be built into the kernel or be compiled as a kernel module.
      Further on the command line one can specify MTD devices to be attach to
      UBI while loading. In the current implementation the UBI driver refuses
      to load if one of the MTD devices cannot be attached.
      
      Consider:
      1) UBI compiled into the kernel and
      2) a MTD device specified on the command line and
      3) this MTD device contains bogus data (for whatever reason).
      
      During init UBI tries to attach the MTD device is this fails the whole
      UBI subsystem isn't initialized. Later the userspace cannot attach any
      MTD to UBI because UBI isn't loaded.
      
      This patch keeps the current behaviour: if UBI is compiled as a module
      and a MTD device cannot be attached the UBI module cannot be loaded,
      but changes it for the UBI-is-built-into-the-kernel usecase.
      
      If UBI is builtin, a not attachable MTD device doen't stop UBI from
      initializing. This slightly modifies the behaviour if multiple MTD
      devices are specified on the command line. Now every MTD device is
      probed and, if possible, attached, i.e. a faulty MTD device doesn't
      stop the others from being attached.
      
      Artem: tweaked the patch
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      af7ad7a0