1. 14 Mar, 2011 24 commits
  2. 13 Mar, 2011 13 commits
  3. 12 Mar, 2011 2 commits
    • Dave Airlie's avatar
      drm/radeon: fix page flipping hangs on r300/r400 · c640e8ca
      Dave Airlie authored
      We've been getting reports of complete system lockups with rv3xx hw on
      AGP and PCIE when running gnome-shell or kwin with compositing.
      
      It appears the hw really doesn't like setting these registers while
      stuff is running, this moves the setting of the registers into the modeset
      since they aren't required to be changed anywhere else.
      
      fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35183
      
      
      
      Reported-and-tested-by: Álmos <aaalmosss@gmail.com
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      c640e8ca
    • Chris Mason's avatar
      Btrfs: break out of shrink_delalloc earlier · 36e39c40
      Chris Mason authored
      
      
      Josef had changed shrink_delalloc to exit after three shrink
      attempts, which wasn't quite enough because new writers could
      race in and steal free space.
      
      But it also fixed deadlocks and stalls as we tried to recover
      delalloc reservations.  The code was tweaked to loop 1024
      times, and would reset the counter any time a small amount
      of progress was made.  This was too drastic, and with a
      lot of writers we can end up stuck in shrink_delalloc forever.
      
      The shrink_delalloc loop is fairly complex because the caller is looping
      too, and the caller will go ahead and force a transaction commit to make
      sure we reclaim space.
      
      This reworks things to exit shrink_delalloc when we've forced some
      writeback and the delalloc reservations have gone down.  This means
      the writeback has not just started but has also finished at
      least some of the metadata changes required to reclaim delalloc
      space.
      
      If we've got this wrong, we're returning ENOSPC too early, which
      is a big improvement over the current behavior of hanging the machine.
      
      Test 224 in xfstests hammers on this nicely, and with 1000 writers
      trying to fill a 1GB drive we get our first ENOSPC at 93% full.  The
      other writers are able to continue until we get 100%.
      
      This is a worst case test for btrfs because the 1000 writers are doing
      small IO, and the small FS size means we don't have a lot of room
      for metadata chunks.
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      36e39c40
  4. 11 Mar, 2011 1 commit
    • Lukas Czerner's avatar
      block: fix mis-synchronisation in blkdev_issue_zeroout() · 0aeea189
      Lukas Czerner authored
      BZ29402
      https://bugzilla.kernel.org/show_bug.cgi?id=29402
      
      
      
      We can hit serious mis-synchronization in bio completion path of
      blkdev_issue_zeroout() leading to a panic.
      
      The problem is that when we are going to wait_for_completion() in
      blkdev_issue_zeroout() we check if the bb.done equals issued (number of
      submitted bios). If it does, we can skip the wait_for_completition()
      and just out of the function since there is nothing to wait for.
      However, there is a ordering problem because bio_batch_end_io() is
      calling atomic_inc(&bb->done) before complete(), hence it might seem to
      blkdev_issue_zeroout() that all bios has been completed and exit. At
      this point when bio_batch_end_io() is going to call complete(bb->wait),
      bb and wait does not longer exist since it was allocated on stack in
      blkdev_issue_zeroout() ==> panic!
      
      (thread 1)                      (thread 2)
      bio_batch_end_io()              blkdev_issue_zeroout()
        if(bb) {                      ...
          if (bb->end_io)             ...
            bb->end_io(bio, err);     ...
          atomic_inc(&bb->done);      ...
          ...                         while (issued != atomic_read(&bb.done))
          ...                         (let issued == bb.done)
          ...                         (do the rest of the function)
          ...                         return ret;
          complete(bb->wait);
          ^^^^^^^^
          panic
      
      We can fix this easily by simplifying bio_batch and completion counting.
      
      Also remove bio_end_io_t *end_io since it is not used.
      Signed-off-by: default avatarLukas Czerner <lczerner@redhat.com>
      Reported-by: default avatarEric Whitney <eric.whitney@hp.com>
      Tested-by: default avatarEric Whitney <eric.whitney@hp.com>
      Reviewed-by: default avatarJeff Moyer <jmoyer@redhat.com>
      CC: Dmitry Monakhov <dmonakhov@openvz.org>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      0aeea189