1. 02 Jun, 2009 3 commits
    • Stephen M. Cameron's avatar
      cciss: fix SCSI device reset handler · 88f627ae
      Stephen M. Cameron authored
      Fix the SCSI reset error handler to send a working, properly addressed
      reset message to the target device and add code to wait for the target
      device to become ready by polling it with Test Unit Ready.
      
      The existing reset code was broken in that it didn't bother to set the
      8-byte LUN address to anything besides zero, so the command was addressed
      to the controller, which pretended to the driver that the command
      succeeded, while doing nothing.  Ages ago I tested this code, but
      unbeknownst to me, my test was flawed, and what I thought was a tape drive
      getting reset was actually nothing of the sort.  Unfortunately, there is
      still lots of Smartarray firmware that doesn't handle doing target resets
      right, and this code won't help in those cases, but it also shouldn't make
      things worse in those cases than they already are.
      Signed-off-by: default avatarStephen M. Cameron <scameron@beardog.cca.cpqcorp.net>
      Cc: Mike Miller <mikem@beardog.cca.cpqcorp.net>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      88f627ae
    • Stephen M. Cameron's avatar
      cciss: factor out core of sendcmd() for a more sane interface · 4a4b2d76
      Stephen M. Cameron authored
      Factor out the core of sendcmd() to provide a simpler interface which
      exposes all the error information to the caller and make the original
      sendcmd use this new function.  Rationale: The SCSI error handling
      routines need to send commands with interrupts turned off, but they also
      need access to the full error information.
      Signed-off-by: default avatarStephen M. Cameron <scameron@beardog.cca.cpqcorp.net>
      Cc: Mike Miller <mikem@beardog.cca.cpqcorp.net>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      4a4b2d76
    • Kiyoshi Ueda's avatar
      block: fix a possible oops on elv_abort_queue() · 53c663ce
      Kiyoshi Ueda authored
      I found one more mis-conversion to the 'request is always dequeued
      when completing' model in elv_abort_queue() during code inspection.
      Although I haven't hit any problem caused by this mis-conversion yet
      and just done compile/boot test, please apply if you have no problem.
      
      Request must be dequeued when it completes.
      However, elv_abort_queue() completes requests without dequeueing.
      This will cause oops in the __blk_end_request_all().
      This patch fixes the oops.
      Signed-off-by: default avatarKiyoshi Ueda <k-ueda@ct.jp.nec.com>
      Signed-off-by: default avatarJun'ichi Nomura <j-nomura@ce.jp.nec.com>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      53c663ce
  2. 30 May, 2009 1 commit
  3. 28 May, 2009 1 commit
  4. 27 May, 2009 2 commits
    • Kiyoshi Ueda's avatar
      block: fix no diskstat problem · 3c4198e8
      Kiyoshi Ueda authored
      The commit below in 2.6-block/for-2.6.31 causes no diskstat problem
      because the blk_discard_rq() check was added with '&&'.
      It should be 'blk_fs_request() || blk_discard_rq()'.
      This patch does it and fixes the no diskstat problem.
      Please review and apply.
      
      ------ /proc/diskstat without this patch -------------------------------------
         8       0 sda 0 0 0 0 0 0 0 0 0 0 0
      ------------------------------------------------------------------------------
      
      ----- /proc/diskstat with this patch applied ---------------------------------
         8       0 sda 4186 303 373621 61600 9578 3859 107468 169479 2 89755 231059
      ------------------------------------------------------------------------------
      
      --------------------------------------------------------------------------
      commit c69d4854
      Author: Jens Axboe <jens.axboe@oracle.com>
      Date:   Fri Apr 24 08:12:19 2009 +0200
      
          block: include discard requests in IO accounting
      
          We currently don't do merging on discard requests, but we potentially
          could. If we do, then we need to include discard requests in the IO
          accounting, or merging would end up decrementing in_flight IO counters
          for an IO which never incremented them.
      
          So enable accounting for discard requests.
      
      <snip>
      
       static inline int blk_do_io_stat(struct request *rq)
       {
      -       return rq->rq_disk && blk_rq_io_stat(rq) && blk_fs_request(rq);
      +       return rq->rq_disk && blk_rq_io_stat(rq) && blk_fs_request(rq) &&
      +               blk_discard_rq(rq);
       }
      --------------------------------------------------------------------------
      Signed-off-by: default avatarKiyoshi Ueda <k-ueda@ct.jp.nec.com>
      Signed-off-by: default avatarJun'ichi Nomura <j-nomura@ce.jp.nec.com>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      3c4198e8
    • James Bottomley's avatar
      block: fix oops with block tag queueing · ba396a6c
      James Bottomley authored
      commit e8939a50466fd963eb1ba9118c34b9ffb7ff6aa6
      Author: Tejun Heo <tj@kernel.org>
      Date:   Fri May 8 11:54:16 2009 +0900
      
          block: implement and enforce request peek/start/fetch
      
      Added a BUG_ON(blk_queued_rq(req)) to the top of blk_finish_req().
      Unfortunately, this checks whether req->queuelist is empty.  This list
      is doing double duty both as the queue list and the tag list, so tagged
      requests come in here with this not empty and boom (the tag list is
      emptied by blk_queue_end_tag() lower down).
      
      Fix this by moving the BUG_ON to below the end tag we also seem
      vulnerable to this in blk_requeue_request() as well.  I think all uses
      of blk_queued_rq() need auditing because the check is clearly wrong in
      the tagged case.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      ba396a6c
  5. 23 May, 2009 1 commit
  6. 22 May, 2009 28 commits
  7. 21 May, 2009 2 commits
  8. 20 May, 2009 2 commits