1. 28 8月, 2006 4 次提交
    • B
      [PATCH] rtc-s3c.c: fix time setting checks · 641741e0
      Ben Dooks 提交于
      Fix the year check on setting the time with the S3C24XX RTC driver.  Also
      move the debug to before the set to see what is going on if it does fail.
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      641741e0
    • R
      [PATCH] swsusp: Fix swap_type_of · b6b5bce3
      Rafael J. Wysocki 提交于
      There is a bug in mm/swapfile.c#swap_type_of() that makes swsusp only be
      able to use the first active swap partition as the resume device.  Fix it.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Hugh Dickins <hugh@veritas.com>
      Acked-by: NPavel Machek <pavel@suse.cz>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b6b5bce3
    • D
      [PATCH] dm: Fix deadlock under high i/o load in raid1 setup. · c06aad85
      Daniel Kobras 提交于
      On an nForce4-equipped machine with two SATA disk in raid1 setup using dmraid,
      we experienced frequent deadlock of the system under high i/o load.  'cat
      /dev/zero > ~/zero' was the most reliable way to reproduce them: Randomly
      after a few GB, 'cp' would be left in 'D' state along with kjournald and
      kmirrord.  The functions cp and kjournald were blocked in did vary, but
      kmirrord's wchan always pointed to 'mempool_alloc()'.  We've seen this pattern
      on 2.6.15 and 2.6.17 kernels.  http://lkml.org/lkml/2005/4/20/142 indicates
      that this problem has been around even before.
      
      So much for the facts, here's my interpretation: mempool_alloc() first tries
      to atomically allocate the requested memory, or falls back to hand out
      preallocated chunks from the mempool.  If both fail, it puts the calling
      process (kmirrord in this case) on a private waitqueue until somebody refills
      the pool.  Where the only 'somebody' is kmirrord itself, so we have a
      deadlock.
      
      I worked around this problem by falling back to a (blocking) kmalloc when
      before kmirrord would have ended up on the waitqueue.  This defeats part of
      the benefits of using the mempool, but at least keeps the system running.  And
      it could be done with a two-line change.  Note that mempool_alloc() clears the
      GFP_NOIO flag internally, and only uses it to decide whether to wait or return
      an error if immediate allocation fails, so the attached patch doesn't change
      behaviour in the non-deadlocking case.  Path is against current git
      (2.6.18-rc4), but should apply to earlier versions as well.  I've tested on
      2.6.15, where this patch makes the difference between random lockup and a
      stable system.
      Signed-off-by: NDaniel Kobras <kobras@linux.de>
      Acked-by: NAlasdair G Kergon <agk@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c06aad85
    • B
      [PATCH] drivers/rtc: fix rtc-s3c.c · 9a654518
      Ben Dooks 提交于
      In the cleanups of drivers/rtc/s3c-rtc.c, the base address for the
      registers got broken.  This patch fixes that by ensuring the readb/writeb
      are all prefixed with the base returned from ioremap()ing the registers.
      
      Also fix check for valid year range, which was the wrong way around.
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9a654518
  2. 27 8月, 2006 23 次提交
  3. 26 8月, 2006 5 次提交
  4. 25 8月, 2006 8 次提交