1. 05 7月, 2009 3 次提交
    • A
      UBI: remove bogus debugging checks · 1398788f
      Artem Bityutskiy 提交于
      The 'paranoid_check_empty()' is bogus because, which is easilly
      seen on NOR flash, which has long erase cycles, and which may
      easilly end-up with half-erased eraseblocks. In this case the
      paranoid check fails. I is just wrong to assume that PEBs which
      do not have EC headers always contain all 0xFF. Such assumption
      should not be made on the I/O level, which is quite low.
      
      Thus, just kill the check.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      1398788f
    • A
      UBI: add empty eraseblocks verification · 40a71a87
      Artem Bityutskiy 提交于
      This patch adds code which makes sure eraseblocks contain all 0xFF
      bytes before starting using them. The verification is done only when
      debugging checks are enabled.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      40a71a87
    • P
      video: sm501fb: Early initialization of mm_lock mutex. · f50bf2b2
      Paul Mundt 提交于
      Commit 537a1bf0 (fbdev: add mutex for
      fb_mmap locking) introduces a ->mm_lock mutex for protecting smem
      assignments. Unfortunately in the case of sm501fb these happen quite
      early in the initialization code, well before the mutex_init() that takes
      place in register_framebuffer(), leading to:
      
         Badness at kernel/mutex.c:207
      
         Pid : 1, Comm:          swapper
         CPU : 0                 Not tainted  (2.6.31-rc1-00284-g529ba0d9-dirty #2273)
      
         PC is at __mutex_lock_slowpath+0x72/0x1bc
         PR is at __mutex_lock_slowpath+0x66/0x1bc
         ...
      
      matroxfb appears to have the same issue and has solved it with an early
      mutex_init(), so we do the same for sm501fb.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f50bf2b2
  2. 04 7月, 2009 1 次提交
    • H
      cciss: Ignore stale commands after reboot · b59e64d0
      Hannes Reinecke 提交于
      When doing an unexpected shutdown like kexec the cciss
      firmware might still have some commands in flight, which
      it is trying to complete.
      The driver is doing it's best on resetting the HBA,
      but sadly there's a firmware issue causing the firmware
      _not_ to abort or drop old commands.
      So the firmware will send us commands which we haven't
      accounted for, causing the driver to panic.
      
      With this patch we're just ignoring these commands as
      there is nothing we could be doing with them anyway.
      Signed-off-by: NHannes Reinecke <hare@suse.de>
      Acked-by: NMike Miller <mike.miller@hp.com>
      Signed-off-by: NJens Axboe <axboe@carl.(none)>
      b59e64d0
  3. 03 7月, 2009 12 次提交
  4. 02 7月, 2009 8 次提交
  5. 01 7月, 2009 16 次提交